Closed Bug 540 Opened 26 years ago Closed 6 years ago

Need feature to edit long description/comments

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P4)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
Harmony
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: terry, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [content:comments] [Implementation: comment 63])

Attachments

(7 obsolete files)

The "edit long descriptions" command doesn't work. At all.
Status: NEW → ASSIGNED
So, for the moment, I have fixed this by turning off the feature entirely (change made to bug_form.tcl).
Component: UI → Bugzilla
Product: Bugzilla → Webtools
Version: 1.0 → other
The database is being reorganized a bit. Instead of the Bugzilla product, a new Webtools product has been created, with Bugzilla being a component of it. This bug is being moved from the old Bugzilla product to the new Webtools product.
Setting all current Open/Normal to M4.
Clearing "M" field since Webtools product is not used for 5.0 specific project bug metrics and will mess up our queries on milestones.
Reassigning to dmose@mozilla.org, who now has front-line responsibility for all Bonsai and Bugzilla bugs.
Reassigning back to me. That stuff about me no longer being the front-line person responsible for Bugzilla and Bonsai turned out to be short-lived. Please pardon our confusion, and I'm very sorry about the spam.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Since the time this bug was filed, it seems Bugzilla has been rewritten in Perl, and is no longer TCL. Therefore, it seems to me this bug no longer applies, and should be marked fixed... Somebody want to verify?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No, actually, this bug survived the translation to Perl. It would be nice to have some code that let people edit the long description. It's also a pretty scary feature to add; maybe only an admin would be allowed to do it or something. Anyway, this bug exists to help remember that such a feature would be nice.
Hmm... Actually, I can understand why it would be scary. I suggest, as a way of preventing just anyone from changing the description at will, why not make it so that only the reporter can change the description? I think this might just do the trick... It would allow the reporter to correct his mistakes, AND prevent others from just changing it on the fly. After all, others can already add additional comments if something needs clarification, and they can already change the short summary if it needs to be changed... And I've already seen people do this before many, many times. Or, I see another possible solution: if a description REALLY needs changing, why not simply mark the original bug as invalid, close it, and open a new bug with a new description? I've also seen this done before. See bug 5207 and bug 5209 for an example of this. So maybe this feature isn't really necessary at all? And after all, if someone REALLY wanted to botch the original description, they could already do this, too. Of course, doubtless there are many other security holes in Bugzilla like this if you look carefully enough. BTW, I do have another suggestion though: perhaps Bugzilla should be able to form links on plural phrases like "bugs 5027 and 5209" as well as how I've done it above, for referring to multiple bugs, highlighting the "5027" and "5209" parts if it encounters the word "bugs?"
Status: REOPENED → ASSIGNED
Priority: P2 → P3
tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Umm... This one appears to have been fixed for a VERY long time. If someone puts the "bug" keyword in, or simply a number that is a valid bug, Bugzilla flags it. You can edit long descriptions (summaries) at will. Let's resolve this puppy.
Matt, did you post that comment to the wrong bug? This one doesn't have anything to do with highlighting bug numbers, and it currently amounts to a feature request that has neither been implemented nor denounced yet (and therefore it should not be closed)
Just reread your comment, and I think you did get the right bug, but misinterpreted what was being asked for. This bug is asking for the administrative ability to edit an existing long description/added comment, which still has not been implemented yet. The feature used to exist, and broke, then this bug report was filed, then the feature was removed when bugzilla got ported to perl. This bug report is still here because Terry said the feature should be restored (it hasn't been yet).
OK, gotcha. I'm not sure I'd want someone going carte-blanche and editing comments outside MySQL. In MySQL, it's trivial to export a comment and edit it. Geesh, we could code up a page for this in an afternoon--but do we want it?
I would find this useful on my site. If for nothing else other than making the comments readable. I have a lot of bug reporters on my site that use browsers that don't support the WRAP=HARD attribute (why should they? it's not part of the standard, it's a Netscape extension :) So I wind up with bug reports that I have to do a lot of horizontal scrolling to read. I've also had situations where helpdesk people will enter a feature suggestion from a customer into the database by pasting in the email from the customer, and it winds up being something that the customer doesn't need a call back on, and should be visible to the public, so it's easier to edit the customer's personal information out of the ticket and remove the group restriction than to open a new ticket. I usually pull out my GUI SQL client and edit them the hard way. Being able to just click an "Edit" link if you have admin privs would be much easier.
I have just created a patch and attached it to this bug that will add a link to edit a description or comment if the user is a member of a new group "editcomment".
Ooh, I like. :) I see you snuck a few extra mime types into createattachment.cgi while you were at it. Not sure if those will go in with this. (That's another bug report somewhere). My personal preference with this would be to see the "Edit this comment" link be part of the "Additional comments from" line, probably at the right-hand side after the final ------, instead of being in the open at the bottom of the comment. For the original description, it could be to the right of the "Description:" header. When editing a comment, it appears that this doesn't give any confirmation that the edit was successful. The "Description edit results" page just has a link back to the bug and that's it. Would be more comforting to see a "Description updated" show up after the update query completes. Any arguments pro/con?
Keywords: patch
Whiteboard: 2.12
i tried applying this patch to the current tip as of 9/1/00, and i get the following error for editdescript.cgi: select login_name from profiles where userid = : You have an error in your SQL syntax near '' at line 1 at globals.pl line 135. I can't figure out where this is coming from.
For some reason you are not getting the select correct. what version of MySql are you running this works with 3.22.32 (RPM r.22.32-1 from www2.analytikerna.se) I had to change the SELECT call in GetLongDescriptionAsHTML to get the user number as well as the name from the Select call. I see, it is getting into trouble in DBI_to_name for some reason (look for login_name in the script and see that on line 585 you can that select call. Have you run checksetup.pl to make sure that your data base is set up correctly
Yeah, I figured it out shortly before you posted. I was going directly to the CGI Since {'person'} was undefined I got the error. So I was playing around with this a bit more, and on the current tip, and I found the following behavior: 1) open a new bug with a new description 2) go and edit that description. 3) display the bug, it shows it as edited 4) go and add a comment to the bug 5) go back and display the bug, the additional comment to the bug isn't displayed. subsequent comments added to the bug are also not displayed in show_bug.cgi. I looked at the longdescs table, and the additional comments are being inserted properly into the table, they just aren't being displayed in show_bug.cgi. Investigating this now. Do you have any idea what's going on here?
hmm...something about the globals.pl change. when i backed that out, all the other added longdesc changes magically showed up.
The UserInGroup() sub uses SendSQL() to look up the user profile to see if they're in that group. SendSQL() is not re-entrant, and since SendSQL() is being used to grab the comments, by looking up the user profile in the middle of the loop you're blowing away the results from the query that retreived the comments. The real fix for this is to change UserInGroup() and several of its counterpart "quick lookup" subs to use the raw DBI with local vars to hold the query results instead of using SendSQL(). An easier fix for this situation would be to look up whether or not the user is in the 'editdescripts' group first and stash it in a variable before querying for the long descriptions.
The latter would actually make better sense here anyway, since it's silly to repetively query the database for the same thing over and over again when you've already got the data and should have stashed it anyway. :)
Attached patch Patch to only find group membership once (obsolete) (deleted) — — Splinter Review
With respect to putting it on the line with "Additional Comments" the reason that I put it on the bottom was that the first comment (description) does not have the "Additional Comments" line.
Which is why I suggested to special-case the first one. :) But it was just an idea, I'll take it either way, just to have it there.
Hi all, Thanks for the patches Philip et al, this was a request from one of my Bugzilla users so it was nice to find other people working on it at the same time. I had applied Philips's first patch (which had the problem with the non- rentrant subroutine) and took a different logical route to things: rather than use "able to edit comment" groups, I decided that only the person that wrote the comment should be able to edit it. Achieved thus (apologies, not using diff/patch software, but goes into globals.pl in Philip's 09/01/00 patch): --- if ($::userid == $uid) { $when =~ s/ /%20/g; $result .= "<a href=\"editdescript.cgi?bug_id=$id&person=$uid&when=$whe$ } --- Cheers, Jeremy.
Whoops - I made a booboo with my post (wish I could edit my previous comment! ;- ) Anyhow, this only works if you pass $uid into the line: my ($who, $email, $when, $text, $uid) = (FetchSQLData()); which is about 15 lines previous. Also, for consistency with the rest of Bugzilla the logic should really be: if (($::userid == $uid) || ($::userid == 0)) { $when =~ s/ /%20/g; $result .= "<a href=\"editdescript.cgi?bug_id=$id&person=$uid&when=$when \">Edit Comment Above</a><br>\n"; } Which gives the 'superuser' of bugzilla comment editing ability along with the original poster of the comment. Apologies for making a mess... Jeremy.
Hmmm. I'm having a problem deciding which patch to take. It would be nice if people could go back at any time and edit comments they have made, it's also dangerous to give that permission to everyone, since it opens the door to people blowing out historical data and rewriting history. If you make it be group controlled, then the power to fix comments belongs to a select few. This is inherently safer, but places a burden on the people who can edit commments to fix typos and mistakes all the time. Comments?
This is something that should almost never ever be done. Playing with history is a dangerous, and very powerful thing. You want the ability to be given only to a trusted few, and those people should never ever use it unless they have a really good reason. It should never be used to fix up harmless typos; it's not worth it! Now, your philosophy may differ. But the code should allow me to support my philosophy on sites I administer.
I agree with your concerns for a bugzilla installed in some situations. However, my personal installation is for a group of a dozen people in the same physical location, which makes it easier to entrust them with editing of prior posts. Also, as the comment is timestamped with a "Edited by" line, it's easy to see where/when something has been edited. On a large, public access bugzilla... I might well think differently. However, as Terry states - the choice should be in the code to support the different philosophies.
So the way I read this, there's actually several classes of prefs. 1) never edit comments 2) edit comments only for people who are group enabled 3) let anyone edit any comments that they make.
and: 4) both 2) and 3)
Also 3' - Let authors edit their comments within some short time period after they've been made - this lets people fix typos, but does not let them "rewrite history". In fact, it would make sence to allow time limits on all the possible choices.
hmm, now that's not a bad idea...
I am on vacation at this time (Diving in FL) and don't have the access to my test system (I did not put bugzilla on my laptop befor leaving) the change to limit the number of days that an item is editable and to allow the author to edit there work is easy, I will make a new patch when I get back (about 28 Sept) and post it here, as alwas I will set it up so an administrator can set the feature on or off as they want.
*** Bug 60443 has been marked as a duplicate of this bug. ***
Phillip where did you go? The promised patch is not here. Removing the 2.12 flag until you return again. Probably will go to 2.14 as I have no time to look at it now.
Whiteboard: 2.12
QA Contact: matty
Whiteboard: 2.14
I think the following things are useful: 1.) Allow people in a certain group to edit all comments. In the default installation, only the maintainer would have this privilege. Currently the maintainer can already do this using SQL, so in theory this would not change much. This feature must be used carefully. 2.) Allow people to edit their own comments for a certain time. Installations that do not want this could set the time limit to 0. Maybe a good time limit would be something between an hour and a day. A possible problem with the second feature is the case where someone else has already posted a followup on your comment, referring to something you want to change. This can occur even in case of typos, grammar errors etc. - Maybe a preview feature (see freshmeat for an example) should be used for this job instead, letting you fix typos _before_ you submit your comment? - Or is it possibile to require confirmation for such a change from the one who already posted a followup? Looks like this is not a practical solution. If you miss something in the preview, is it really so bad if only a certain group of people can change it? Other possibilities that may be worth thinking about, especially useful for long bugs: - Introduce a new "long summary" field with the original bug description as the initial value, and make it editable by everyone with the editbugs permission (and maybe the reporter). In a bug view, this field should only be shown if its value is different from the original bug description, or alternatively it should always be shown, replacing the initial bug description field (with a clear visual indication that it serves a different purpose than the additional comments). The history of the changes to the bug description field should be stored as a sequence of diffs, conceptually like CVS version files, and each diff could show up as an additional comment. This way, the additional comments would be more like a discussion log, whereas the "long summary" field would always contain a detailed, up-to-date description. This would be a useful feature for everyone who is short of time and wants to get the "details" of a bug (like PDT) without having to scan through all the comments. - Alternatively, something similar could be achieved with a simpler, but less beautiful hack: Have a link at the beginning pointing to the "most recent detailed summary comment". By default, it points to the original bug description (and in this case it need not show up in the bug view at all), but anyone with editbugs priviledges can change it to point to an arbitrary comment. This way one could always jump to the important comments quickly. Additionally or alternatively, there could be such a "pointer to a comment" that causes all previous comments to be hidden from the default bug view and only be displayed on demand (a "show all comments" link, or a "show previous comments"). What do you think? How many new bugs should be filed for these suggestions?
Summary: Editing of long descriptions is completely horked. → Editing of long descriptions (comments) is completely horked.
Whiteboard: 2.14 → 2.16
moving to real milestones...
Target Milestone: --- → Bugzilla 2.16
Please see the "Other possibilities..." section in my 2001-02-19 23:38 comment.
-> Bugzilla Product, Creating/Changing Bugs
Assignee: tara → myk
Status: ASSIGNED → NEW
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
Whiteboard: 2.16 → [content:comments]
Andreas numbers: 1) is the additional complexity of Bugzilla UI worth the usefulness of the feature? 2) All of these ideas are pretty complicated, and would add complexity. Again, I don't think doing this is worth it. Like Terry said, changing history is bad, and can only lead to confusion or worse. Gerv
Keywords: patch
The only justification I would use for this is fixing line-wrapping, and eliminating comments that contain confidential data in a bug that already has lots of comments in it. To me, especially on a very open-to-the public bug system, eliminating a single comment that contains confidential data makes much better sense than making the entire bug confidential, thus losing all the comments everyone else has already made. It'd be a rare case, but those are the only reasons I would use it. If it's put in, it should be a param whether to allow it on not at all, default to off, and if it is a allowed, only the admin would be able to do it.
I think comment deletion is another matter than editing. Deletion is OK, editing I wouldn't support, except to change the privilege level required to read a comment if and when we have confidential comment support.
Since some of my comments seem to get buried here, I have filed them as separate enhancement requests: Bug 99240: Add an editable "long summary" field (useful for long bugs) Bug 99242: Link to "most recent summary comment", or hide old comments The request for a preview feature is Bug 40896: Bugzilla needs a "preview" mode The request to correct errors in the last comment is Bug 53514: Ability to cancel last posting
This is really an RFE, given that we haven't had it for years. As an RFE with no patch, -> 2.18. If someone writes one, please feel free to put the milestone back. Gerv
Severity: normal → enhancement
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
We don't have an edit longdescs feature to be hornked, changing summary
Summary: Editing of long descriptions (comments) is completely horked. → Need feature to edit long description
This shouldn't be used for censorship or to change a comment from "This is taking too long" to "I like the progress being made on this". This feature is ripe for abuse, and I think that any editing of comments should be admnistered itself. Also, it would be nice if you could edit your own comments as that is what my bug that got duped was about. I think you should be able to edit your own comments for a reasonable amount of time. Maybe 1 hour? <OFFTOPIC> You should also be able to edit your own attachments for a limited amount of time </OFFTOPIC>
*** Bug 140476 has been marked as a duplicate of this bug. ***
Comment on attachment 13871 [details] [diff] [review] This is a patch to add a [group controlled] editing of the descriptions This has really bitrotted, + theres doubt that we should do this at all ->needs-work
Attachment #13871 - Flags: review-
Comment on attachment 14032 [details] [diff] [review] Patch to only find group membership once I don't see the point to this part, + see the other comments
Attachment #14032 - Flags: review-
*** Bug 161470 has been marked as a duplicate of this bug. ***
> Also, it would be nice if you could edit your own comments > as that is what my bug that got duped was about. Yes. I just had my own new bug 161470 marked as a dupe of this. I'm not entirely happy about it because I'd opened my bug on editing *comments* not on editing the *long description*, so I didn't think it was a dupe. If it is, can we please change the Summary for this bug to reflect that? (I.e. "Need feature to edit long description and comments".) If not, one of us (Brian obviously), should reopen their own bug.
The long description is a comment, they're the same thing. Internally, the long description is just the first comment on a bug, and unless the default templates have been modified, it even looks that way on the show_bug page. Modifying summary to help keyword searches succeed.
Summary: Need feature to edit long description → Need feature to edit long description/comments
FWIW, I would like to see this feature implemented. Specifically, the ability for a user to edit *their own* comment, for a (admin defineable) period of time. Also, it makes sense to enable a feature to allow the administrator to edit comments, since he/she can easily do it directly in the database with SQL anyway. I do understand why Gerv and others say that "changing history" is bad, and I largely agree. However, I would think that Bugzilla should, as much as possible, allow the administrator of a particular site to make these choices. Call it personal philosophy, but I think tools should (within reason) conform to the user's methodology, and not enforce a methodology on it's users. In my own case, I just cannot stand it when I make a typo in a comment, and am forced to leave it there. Yeah, call me anal or pedantic or whatever, but it just annoys me... I'd absolutely love a window of time where I can go back and fix mistakes like that. Could even that facility be abused? Yes. Is that a big deal? I say that that is for the site admin to decide. In my own case, I administer a Bugzilla server for my company, and if the option were there, I would allow users to edit comments, for probably 1 hour or so.
If this feature is implemented, the editing history should be immediately accessible to users. I suggest below the description label and the description field put something like: Edited by <a title="'COMMENT' (DATE)">EDITOR_NAME</a>, <a title ....>
*** Bug 186139 has been marked as a duplicate of this bug. ***
When a bug is extended, i.e. more bugs are added to the original description of the bug, the owner/reporter should be able to edit(or add text to) the original description so that everyone who reads the bug knows what issues are being handled in the bug without the need to read all comemnts. Bug extending(or bug generalization) is a common issue in b.m.o, so, I think this feature will help to reduce the dupes on bugs.
I believe this is not OS-specific.
OS: Windows 95 → All
Hardware: PC → All
Just an observation that I'm making at the risk of stating the obvious (but it's also bad to assume things). If / when this bug gets fixed, I don't want to be "SPAM"med with email messages about "so and so has changed comment x to comment y". I know that I frequently make typos and would be correcting those just as frequently - both assuming I notice them and that the resolution of this bug allows things such as typos to be corrected. If I were on the cc list for the bug, I know I'd be annoyed to be getting notification of me making those changes. So, anyway, just a note that either a comment change shouldn't generate automated messages to lists or that an option to not receive such notification should be added to user preferences.
Just a thought. I know this would probably make the resolution to this bug not- so-trivial, but it might make all parties happy. Why not add two fields to the longdescs table : 'comment_id' and 'overrides'. After patching Bugzilla with the patch that adds these two fields, checksetup.pl would assign sequential numbers to each comment for the 'comment_id' field, and would set 'overrides=NULL' for each one. Then, let's say user 'bob' edits their comment, which is 'comment_id=15149'. The new comment would be added as any comment, for example, 'comment_id=457498', but the difference would be that it would have 'overrides=15149'. show_bug.cgi would then display the comments, but when a comment is overriden by another one, the new one is displayed, with a line like the following at the top or bottom : Edited by <who> <bug_when> (Original comment) ^^^^^^^^^^^^^^^^ link to show_comment.cgi?id=15149 (show_comment.cgi = new script, but wouldn't be too complicated, just displays the comment...) The advantages : - No "rewriting history" since the original comment is still available, and if an admin doesn't like the edit that was made, he can just delete the new comment's row from the longdescs table. - Easily scales for multiple edits, and could look like this : Edited by <who> <bug_when> (Previous comment) Which was Edited by <who> <bug_when> (Previous comment) Which was Edited by <who> <bug_when> (Previous comment) Which was Edited by <who> <bug_when> (Original comment) (just a suggestion...) Personally, I have no interest in this bug. I have never found any use for editing my bugs, because I find typos harmless, and my Bugzilla is internal, so I have no confidential informations I need to edit out. So please still consider, if this is implemented, to control its activation with a parameter.
How do I actually remove an attachment manually?
*** Bug 214226 has been marked as a duplicate of this bug. ***
*** Bug 218458 has been marked as a duplicate of this bug. ***
Depends on: 225221
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comments like this should be edited
Okay...a little help for a true newbie. I have added a new subroutine to the globals.pl file. I cannot receive any return values from it. Is there a compilation or special procedure that needs to take place before a template can access the subroutine?
*** Bug 252907 has been marked as a duplicate of this bug. ***
I think the idea in Comment 63 would be a good solution for this bug. A easier solution would be ths possibility to mark comments as obsolete (like with attachments). This would solve the 'changing history' problem because the original comment remains and you get the possibility to mark false comments so that they dont lead to further mistakes.
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
If changes to comments are noted in the 'Activity Log', the fears of 'changing history' are minimized. The activity log would keep a record of who changed comments, and what the changes were.
I hope that this is the place where I can get help. Last night I was doing my school work on the computer when this this came up something about profile. It said something about me making a profile name and I did, and then when I pressed "OK", firefox kinda blinked, i guess that's how you could describe it. And then I needed to go look up something on the internet and I always use firefox. But I went up to my "Bookmarks" and there was nothing there. I had a ton of places that I put into my bookmarks because i need those and now they're gone. I really need this to change back to the way it was before this happended 'cause I liked the other way better and I had no problem with it. But now, I have a problem, and that is not having all of those neccessary bookmarks. So please help. You can contact me at hurtfulstars@yahoo.com . Thank you.
hurtfulstars@yahoo.com: Bugzilla is not a help forum, and this bug has absolutely nothing to do with your problem. Please use http://forums.mozillazine.org/ instead.
I agree -- comment 63 is the way to go. I don't think it would be too hard. We already have a template that prints only one comment.
Whiteboard: [content:comments] → [content:comments] [Implementation: comment 63]
What the heck, let's assign it to me. We'll make it a parameter, too: allow_comment_editing or something like that. OK, so the next question is security of comment editing. I think it probably works like this: + People who wrote comments can edit their own comments. + New permission, editcomments, for people who can edit all comments. And those are the ONLY ways to edit comments. The reason for a new permission is that even people with editbugs shouldn't be able to change *other people's comments* without explicit permission. People with "editcomments" would essentially become moderators -- it's a privilege closer to "admin" than to "editbugs." Any other special abilities, like "assignee should be able to edit comment 0" and stuff like that, can go in some other bug.
Assignee: myk → mkanat
Any administrative ability to edit comments should include the ability to do so without leaving the original in the database. As a b.m.o administrator, I've never edited a comment except to remove confidential information, and in those cases it's never possible to leave an original version of the comment behind.
In addition to everything mentioned in Comment #63, Comment #76 and Comment #77 We should add another permission -> deleteComments. That will allow to irreversably delete a comment (for an admin who wants to remove confidential information).
(In reply to comment #78) > In addition to everything mentioned in Comment #63, Comment #76 and Comment #77 > We should add another permission -> deleteComments. That will allow to > irreversably delete a comment (for an admin who wants to remove confidential > information). OK. If you want that, file another bug for it. Of course, the best way to do that now is to make the comment private so that only the insidergroup can do it.
Blocks: 282657
Priority: P3 → P2
Well, glad somebody's worried about it. I'm so tired of typo mistakes in my damn reports (2, I think, ever filed) and anybody elses. Give them a option to correct their mistakes. Or, how about a "typo/spell check" option that sends it to an cosmetic/spell checker admin and he fixes it or grants permission for the author to fix his mistake (with some kind of script limiting deletion of words but allows letters to be rearranged). Also, IMHO, leaving behind a copy of the original description is sloppy. Maybe we can have a "Review for redundant/sloppy activity log", then a "cleanup" admin could come along and decide for himself. Unless you guys are impling the underhandedness going on in the ranks and ability not to trust anyone in the staff wholeheartedly...
Descriptions should be treated differently from comments. They should be editable as other fields like the summary field is.
In this enhancement are you looking to preserve any changes a user makes on the "edit bug" page? Or if changes are made they will be lost due to the page going to editdescript.cgi and then giving the option to go back to the bug. Maybe a popup window might be better this way you edit the description then close the window and you didn't change the page of your original window. The only downside is your changes you just made to the desciption/comment will not be seen unless you refresh your page which will cause nothing to be preserved.
Flags: blocking2.20?
Flags: blocking2.18.4?
Flags: blocking2.16.11?
This is a huge new feature, very much not a blocker.
Flags: blocking2.20?
Flags: blocking2.20-
Flags: blocking2.18.4?
Flags: blocking2.18.4-
Flags: blocking2.16.11?
Flags: blocking2.16.11-
Is there any patch I could use _now_ to enable users to edit their bug comments? If not, my users want another system... We use bugzilla for custom development in trusted environment and it isn't publicly accessible at all. So "history changing" is almost not an issue.
Pushing for activity, please. Especially since Bugzilla 2.20 was added and this wasn't included.
2.22 has already frozen, but let's see if we can get it into 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24
This may be a huge amount of work to fix, but it is an important one to consider. Commercial bug tracking software apps treat descriptions/comments much better. I understand the philosophical objection to 'changing the past', but with revision history stored that shouldn't be an issue. See WikiPedia for a decent interface for viewing who changed what when, without everything being listed on the finished page itself! See StarTeam change requests for how to edit defect reports and then see "diffs" between various historic versions of the defect report.
QA Contact: mattyt-bugzilla → default-qa
*** Bug 346368 has been marked as a duplicate of this bug. ***
No longer blocks: 282657
Target Milestone: Bugzilla 3.0 → ---
(In reply to comment #87) > This may be a huge amount of work to fix, but it is an important one to > consider. Commercial bug tracking software apps treat descriptions/comments > much better. I understand the philosophical objection to 'changing the past', > but with revision history stored that shouldn't be an issue. See WikiPedia for > a decent interface for viewing who changed what when, without everything being > listed on the finished page itself! See StarTeam change requests for how to > edit defect reports and then see "diffs" between various historic versions of > the defect report. > this is a test reply only ....
Flags: documentation+
Flags: approval?
(In reply to comment #87) > This may be a huge amount of work to fix, but it is an important one to > consider. Commercial bug tracking software apps treat descriptions/comments > much better. I understand the philosophical objection to 'changing the past', > but with revision history stored that shouldn't be an issue. See WikiPedia for > a decent interface for viewing who changed what when, without everything being > listed on the finished page itself! See StarTeam change requests for how to > edit defect reports and then see "diffs" between various historic versions of > the defect report. > this is a test reply only ....
(In reply to comment #90) > this is a test reply only .... Mozilla's Bugzilla is not a place for testing. If you want to test out Bugzilla, please use http://landfill.bugzilla.org/.
Flags: documentation+
Flags: approval?
(In reply to comment #87) > This may be a huge amount of work to fix, but it is an important one to > consider. Commercial bug tracking software apps treat descriptions/comments > much better. I understand the philosophical objection to 'changing the past' I also understand the philosophical objection, but for me the aesthetic/usability issue is much more important: ie. the fact that someone can post an extremely wide comment and it will alter the width of the entire page, requiring lots of horizontal scrolling. Not only is it ugly, it has a negative usability impact as well. The ability to go back and fix up typos is a bonus, but it pales in comparison to the ability to fix line and page-widths. As such, the ability for admins to conveniently edit such comments from within Bugzilla would be extremely helpful. As things currently stand, manipulating the database by hand is the only alternative. Or suppressing the problem comment by marking it as "insiders only" (but even then, insiders still have to put up with the excessive page widths). To illustrate the problem, here's a bug that I just posted in my own install (Bugzilla 2.22 series): http://wincent.com/a/support/bugs/show_bug.cgi?id=504 The long lines cause the entire page to become wider, requiring horizontal scrolling in order to read it. (As a side issue, note how I unwittingly triggered the long lines by starting the line with a ">", trying to quote it; as noted in bug #11901, quoted paragraphs are left unwrapped... which makes me wonder if there is a way for me to manually quote text without having to hard wrap it myself...)
Priority: P2 → P3
I have the following reasons for changing the "long description": 1) typ-o in the text. 2) Over the lifetime of the bug, the initial description may need to be updated to better describe the actual bug. In the case of this bug, a more accurate description is "A bug's long description is not editable." The fact that the long description is stored as a comment is not relevant to the user. Thus the discussion around editable comments may not apply. That said, comment #63 provides a way of tracking the history of the description/comment.
Hello, just to say that a feature to be able to edit comments and description is really wanted here too. In my company we use a **** bug system and want to switch. I am currently trying to get bugzilla on top of the list, but I know that some people in R&D are currently trying other softwares (proprietary one). I have not done my demonstration with bugzilla yet, but I fear that one blocking point may be this impossibility to edit comments (because in the current bug system we use, people often change the last comment). What would be good is to set several possible kinds of permissions: - edit the description; - edit only one's comments; - edit only the last comment (if it is yours); -> this enables to change only your unanswered comments (for the philosophical objections about changing the past); this is how it currently works with the current bug system we use and I think it a good compromise. Any of these above permissions would let an history of change (maybe a link in the comment header?). And some other permissions that should be enabled only to people with admin rights: - edit any comment; - delete comments; - edit/delete without history (a special option for editing/deleting irreversably, all the considerations above about confidential info to remove for instance).
Priority: P3 → P4
It's coming up to the 10 year mark since this bug was created... I really think comment#63 and #76 have some potential here. Max Kanat-Alexander, any updates? Obviously hierarchy/security are issues that need to be discussed and planned out. Essentially, say a full edit feature IS implemented... this means that the next version, of say for example the bugzilla running HERE on mozilla.org, will have the facility for the entire database history to be edited. If the "#1 maintainer"'s account gets compromised.. then the hacker could delete everything in the bugzilla.mozilla.org DB. Not good. I think that modern WikiWiki implementations can be studied for a good example in this context. (As far as reverting vandalized history, and security, etc.) One thing I think would be smart is to allow the author of a bug to edit any comment in the bug. The author of any comment can edit his own comment, (obviously that's the whole point) And the next issue is how to control the edit status. Most message boards display an indicator like 'this message was edited by ** at **'. For starters, I think this should be enabled by default and permanently, until the security issues related to that specific topic have been further discussed. For example.. say I'm posting a bug and I'm being sloppy about my window management while multitasking... I somehow post the bug with a password to some account in the message because, you know, 'oops, wrong box'. I edit the comment, removing the password. BUT, it says 'edited by ** at **'. Obviously you'd want such a mistake to have no record whatsoever, just for peace of mind. You don't want others to be thinking 'hmm wonder what he edited', when in fact is was such a grave mistake. Like most things, this can also be reverse/negatively exploited. But I'll let you think of that for your self. ;x
I admit the even when checking for spelling and context errors, I still make plenty of mistake. Seamonkey helps with spell check but only for unique words and never Specific thins like URLs or such. I have been using Betanews for some time and when I post a comment that is factually wrong or has a spelling error or a context error or the copy and past forget to modify the text error, then when I am logged in then I can click poster comment and the original comment is reopened in an text box and I can modify it to my hearts content until my meaning is quite clear and my spelling is perfect. This is very important since exact information needs to be reported and a simple typo can really change it's meaning. Please refer to this bug that I screwed up and see how bad it is having try and fix the unique text that is vital to the meaning. I still made a mistake in the correction and it makes me look stupid. Yes it was one of a millions things I was doing that day and I didn't have much time to get my point across and I missed a fews vital things. Having a simple process like the one Betanews uses would give peace of mind especially for inexperienced people who are nervous at just the prospect of posting a bug and getting it wrong. The first time I posted a bug a number of years ago, after trying for 30 minutes to determine where it should go posted a bug in the place that it made sense to put it. I got a very rude reply, something like "This bug is not in the correct location. You must spend the time to get it in the right place. Bug deleted" It took 5 years before I even attempted to file a bug. People are better now at moving posts and being civil, but it is still very daunting. Not every one is a pro or a hacker so this would make it one step more friendly to use the site. Please reconsider and make this a priority. Thanks you
(Correction for comment #96) Here we go again... The bug that I am referring to is: https://bugzilla.mozilla.org/show_bug.cgi?id=408885 I also found a couple typos again that I missed and I just hope that the meaning is clear at those points.
I don't know what happened, I tried to add myself to the cc: list aqnd every one was deleted. Sorry, I guess this needs fixing. Here is the list so it doesn't get lost: me@jackieliu.org, kniht@us.ibm.com, eyalroz@technion.ac.il, A.Kuckartz@ping.de, bugbot@landfill.bugzilla.org, prognathous@bluebottle.com, jaime.bugzilla@gmail.com, mozilla.mail@gmail.com, ispence@gmail.com, andreas.christl@de.bosch.com, remember.pol@gmail.com, roni_abusch@msafe.com, barnboy@trilobyte.net, marcoos+bmo@marcoos.org, foxymonkies+archive@gmail.com, tenorman777@yahoo.com, justdave@bugzilla.org, ancestor.ak@gmail.com, bugzilla@chimpychompy.org, gavin.bugzilla@gmail.com, tjholly@gmail.com, mozilla-bugs@nogin.org, bl@vitronic.com, aaronw@net.com, jasonb@dante.com, bugzilla-mozilla@bkor.dhs.org, shimono+sbo@gmail.com, firebot@psychoticwolf.net, LpSolit@gmail.com, Chris.Yeh@nokia.com, prodigion@hotmail.com, joules@gorfajn.com, fe@alterplast.ru, phillip.stewart@gmail.com, kennon@skyflow.com, dan.lambert@noa.nintendo.com, krystaiceman@yahoo.com, gunnar@wagenknecht.org, cb13@gmx.net, phil_mozilla@cpphacker.co.uk, jng@cambridgeassociates.com, reed@mozilla.com, bugzilla@tuxmachine.com, miguelangel.alonso@altana.es, terry@mozilla.org, brad0112358@yahoo.com, bugzilla@steenhagen.us, matthias.thullner@de.bosch.com, mozilla-linux@srasku.net, danielwang@mozillanews.org, altlist@gmail.com, raj@lordofthemoon.com, paulspencer@mindspring.com, basic@mozdev.org, mkanat@bugzilla.org, timeless@gmail.com, afranke@mathweb.org, kbenton@yitr.com, gurganbl@rose-hulman.edu, vladd@bugzilla.org, zain@voltage.com, veshi@veshi.com, drag0n2@hottermail.net, oliver@samera.com.py, wurblzap@gmail.com, deletesoftware@yandex.ru, jehan@zemarmot.net, wicked@sci.fi, t8m@centrum.cz, Pidgeot18@gmail.com, anthony@derobert.net, webmaster@eclipse.org, raybooysen@rjb.za.net, zach@zachlipton.com, BijuMailList@GMail.Com, iezibeij-bugzilla.mozilla.org@wincent.com, mark@petrosys.com.au, jean_seb@videotron.ca, dopefishjustin@gmail.com, spreadthunderbird+bmo@gmail.com, pierre42d@9online.fr, default-qa@bugzilla.bugs, logixoul@gmail.com
(In reply to comment #76) > We'll make it a parameter, too: allow_comment_editing or something like that. > ok > OK, so the next question is security of comment editing. I think it probably > works like this: > > + People who wrote comments can edit their own comments. mhh, that might cause a hell of confusion. Assume that I write a comment that states something that is commented later on if referenced comments. If I would now change the comment and state something completely different, the bug's comment history would be damaged. I would suggest to leave only the "editcomments" permission and all users should discuss their issues with a "semi-admin" with editcomments permission. The rest should be put into a later bug. Maybe something like "Allow to edit comment x for bug y" can be assigned by an admin or a person that has grant permission on editcomments to any user that has written a comment. > + New permission, editcomments, for people who can edit all comments. ok > > The reason for a new permission is that even people with editbugs shouldn't be > able to change *other people's comments* without explicit permission. People > with "editcomments" would essentially become moderators -- it's a privilege > closer to "admin" than to "editbugs." ok >
I think there are 2 issues here. As the bug gets more comments, people want a place to understand the current plans for the bug, like an extended summary. 1. The first comment aka "Description" is viewed by most users as exactly that, not "comment 0". 2. Comment lists can get long and cumbersome, especially if plagued with minor edits and corrections. I suggest, in addition to allowing users to reply to a comment, the author of a comment (commenter) should also be able to "supersede" their comment. Superseded comments would remain in the comment list as-is (default collapsed to reduce space use), and with a link to the superseding comment. As a special case, a subset of users (I suggest only the Author and Assignee, as an extension only if they have permission) could mark the description as superseded, which would put a copy of the description superseding comment in the "description" location, with a "supersedes" link to "comment 0" which would be the original description (default collapsed). Multiple supersedes would be handled by providing the transient set of links - ie ------- Comment #99 <details> (+) [reply] ------- superseded by comment 102 superseded by comment 105 and ------- Comment #105 <details> (+) [reply] ------- supersedes comment 102 supersedes comment 99 In order to support this 1 additional column would be required, either supersedes or superseded, depending on ease of implementation of link direction.
(In reply to comment #99) > > OK, so the next question is security of comment editing. I think it probably > > works like this: > > > > + People who wrote comments can edit their own comments. > mhh, that might cause a hell of confusion. Assume that I write a comment that > states something that is commented later on if referenced comments. If I would > now change the comment and state something completely different, the bug's > comment history would be damaged. I would suggest to leave only the > "editcomments" permission and all users should discuss their issues with a > "semi-admin" with editcomments permission. > The rest should be put into a later bug. Maybe something like "Allow to edit > comment x for bug y" can be assigned by an admin or a person that has grant > permission on editcomments to any user that has written a comment. why not handling this bugzilla request the way we think it should be done: 1) make the comment0 editable, so you have a comprehensive summary of bug discussed many times 2) create a new (clone) bugzilla request for superseding comments (making them editable) specially for this very entry it would be nice to see what is going on without reading over 100 comments (over years again and again :-()
please edit my comment#101 summary of bug -> summary of bugs :->>>>
> If I would now change the comment and state something completely > different, the bug's comment history would be damaged. How about allowing a comment to be freely edited if it's only been posted within the last minute or so? That would then take care of people who just want to fix obvious typos and other mistakes (that, personally, I only notice immediately after it's too late) - but still prevent anything else from being changed after the fact?
Sounds good -- reminds me of the way Digg handles it.
Hello, I have tried to apply the patches, but have so far been unable to. Would it be possible to have step-by-step instructions to do so? Thank you.
(In reply to comment #105) Delzoun those are old old old old patches which are almost certainly unusable at this point... with current releases. (In reply to comment #103) > How about allowing a comment to be freely edited if it's only been posted > within the last minute or so? That would then take care of people who just > want to fix obvious typos and other mistakes (that, personally, I only notice > immediately after it's too late) - but still prevent anything else from being > changed after the fact? Yes, but you've already email spammed unless you are running you email as a cron script.. I would say that if this were ever implemented that it needs to be default disabled in administrative parameters. Some (many?) organizations and companies will not want this ability. Alternatively you should at least keep the original comment as well and make it viewable. Perhaps formatting of: comment 1 -view state collapsed- comment 1.1 -view state collapsed- comment 1.2 -current version- -view state expanded- comment 2 -current version- -view state expanded- This would not require really that significant of changes to make work. Where you run in to a problem is existing third party integrations.
Depends on: 531269
Assignee: mkanat → create-and-change
How long we have the feature that enable edit comments?
Resolved-Invalid: use http://trac.edgewall.org/ instead.
Please, no responses to comment 109. Do Not Feed The Trolls.
I've just added myself to the list of votes. Ad a BZ admin, I regularly have to go into the DB backend to remove sensitive information in comments.
Attached patch remove_comment.patch (obsolete) (deleted) — — Splinter Review
Hi, I try to make this function. But, it is very scrawled version. It is following behavior: 1) permit admin's Group to remove Comment. 2) It can just only *remove* Comment. (more properly, overwrite comment)
I make second version This version is: -admin and comment owner Can edit comment. -add a history of the changes to the Comment X to History table. -if comment was edited, Always add message as "*** This comment was Edited ***" to message end.
Attached patch v2 (obsolete) (deleted) — — Splinter Review
I check on version 3.6.4
Attached patch v2.1 (obsolete) (deleted) — — Splinter Review
Fix few lines.
Attachment #515466 - Attachment is obsolete: true
I found I can not edit the comments in the list. Does it have bearing one this bug? I am using bugzilla 3.4.
(In reply to comment #118) > this bug? I am using bugzilla 3.4. Probably you can use the attachment 516092 [details] [diff] [review] on bugzilla 3.4. After patched it, "edit" link is displayed on each comment header. If you have test environment, please try it.
Is the patch compatible with bugzilla verson 4.x ?
(In reply to Michael Borchers from comment #120) > Is the patch compatible with bugzilla verson 4.x ? When I try it on test environment, It can patch, and it's works But, I don't check well which point change from version 3.x to verson 4.x yet.
(In reply to Yuta Sugiura from comment #116) > Created attachment 516092 [details] [diff] [review] [diff] [details] [review] > v2.1 Yuta, thanks for providing a patch. If you want your patch to be accepted, you have to go to "Details" of your patch, set Review flag to ? and add the email address of an appropriate reviewer / module owner. Try Max Kanat-Alexander. Without review flag, this will not get attention.
(In reply to Yuta Sugiura from comment #116) > Created attachment 516092 [details] [diff] [review] [diff] [details] [review] ...and make sure 'Assigned To' field is changed to your mail address if you are working on a patch for the bug (I've done that for you).
Assignee: create-and-change → yuta.sugiura
Comment on attachment 516092 [details] [diff] [review] v2.1 (In reply to Thomas D. from comment #122) > you have to go to "Details" of your patch, set Review flag to ? and add the > email address of an appropriate reviewer / module owner. Try Max > Kanat-Alexander. Without review flag, this will not get attention. Thank you for your response. It would make me happy. if it will be testbed.
Attachment #516092 - Flags: review?(mkanat)
Attached file attachment patch (obsolete) (deleted) —
It is an attachment patch.
(In reply to gsaranyamca from comment #125) > Created attachment 577199 [details] > attachment patch > > It is an attachment patch. ignore the above comment. Made in a wrong place.
Attachment #577199 - Attachment is obsolete: true
What is the release plan concerning the patch provided by Yuta? Will it be included in 4.2?
(In reply to gianni.pucciani from comment #127) > What is the release plan concerning the patch provided by Yuta? > Will it be included in 4.2? It's way too late for 4.2.
Comment on attachment 516092 [details] [diff] [review] v2.1 >+++ editcomment.cgi 2011-03-02 09:13:38.000000000 +0900 I don't think we need another CGI script to edit comments. This should be done from show_bug.cgi directly, e.g. by using a checkbox or some "edit" link besides the comments you can edit. Probably you should also only be allowed to edit newer comments, but not older ones, e.g. if delta_ts didn't change since you commented. >+ my $bug_id = $cgi->param('bug_id') || '0'; Falling back to 0 doesn't make sense. Moving all the logic into Bugzilla/Comment.pm and letting process_bug.cgi use it would save you a lot of trouble. Security checks would be done by process_bug.cgi itself.
Attachment #516092 - Flags: review?(mkanat) → review-
Blocks: 53514
I have found miles of discussion in the matter of changing comments, this seems like a logical place to put my proposal. Bugzilla documentation basicaly says, that comments are not editable to maintain the logical context of discussion(comments and replies). How about adding possibility to mark comment as invalid and display it either with different background color, or with striketrough text? The logical context of discussion is still there if you need it, and you can see on the first sight what is not worth reading if you need only some shallow information. Motivation for this proposal was that it happened to me several times, that I had several bug documents opened in tabs in explorer, and I accidentally committed comment to different document than where I wanted. It would be nice to have possibility to somehow mark it as rubbish
Interesting proposal. Who should be able to "invalidate" a comment and when. For example, can the commenter invalidate their own comments forever or for a limited amount of time (e.g. 30 minutes). I don't think that anyone should be able to invalidate someone else's comments but perhaps someone with sufficient privileges could.
If you look at https://bugzilla.mozilla.org/show_bug.cgi?id=781394, you'll see that I made comments 33 and 34, which are identical. What happened was a "mid-air crash". The problem was that I didn't understand the ramifications of the two choices I was given and, basically, guessed wrong. I'm a native speaker of English and an English teacher, so I can't blame it on inadequate language proficiency. Maybe it's just innate stupidity. In any case, where can the texts of the choices be found, please? I'd like to have a crack at rewording them. In closing, I'd like to observe that my error is a good example of a reason for authors being able to edit or delete their own comments.
After apply patch, I need to run checksetup.pl hook, Is it right? Thank you very much. (In reply to Yuta Sugiura from comment #124) > Comment on attachment 516092 [details] [diff] [review] v2.1 (In reply to > Thomas D. from comment #122) > you have to go to "Details" of your patch, > set Review flag to ? and add the > email address of an appropriate reviewer > / module owner. Try Max > Kanat-Alexander. Without review flag, this will > not get attention. Thank you for your response. It would make me happy. if > it will be testbed.
I think the fact that a bug first filed in 1998 still has "Status: NEW" is as good a reason as any sane person would need to get an "edit" feature implemented - sooner rather than later. With all due respect, considering what's happened in the world of computing since bug 540 was opened - back in 1998 - I have to ask myself how the people concerned can even look themselves in the mirror. A patch was cooked up in October 2011 (comment 124), a year ago, but it appears dead in the water. Another comment that appears to be patch-related (135) was made a month ago and has yet to be replied to. (I must confess, though, that I find this comment hard to make sense of.) On the other hand a new bug filed that happens to be a dupe of this one is marked as such the very same day, so it's not as if no one is following this bug. I know trolling is "illegal" here, and it's not really my intent; nor is "provocation." I'd just like to get some kind of reaction from the "people in charge." Frankly, gentlemen, the arguments against implementing a simple edit function for comments range from recondite to downright arcane. On the other hand, if it's a manpower problem, I think someone should call a spade a spade. I'd like to end this comment with a comment: Now, having done a bit of looking around Bugzilla for the very first time, I've all of a sudden come to understand why bug 540, which is very much a "user-experience" issue hasn't had much attention of late. http://guy-pyrzak.blogspot.de/2012/08/where-has-guy-been.html. P.S. As much as I'd like to see an edit function for comments, I find Curiosity much more interesting - and important. P.P.S. Please excuse me if this comment appears gratuitous, frivolous, or both. Given the bug's duration and apparent resistance to resolution, my ultimate hope in making it is to focus a bit more attention on it.
At the very least, allow a 10 minute or so grace period after posting a comment to allow you to edit it and if there is another comment left after the one you wish to edit, don't allow it. Literally 2 minutes after I posted a comment I realized that I could have worded my comment better but rather than editing it I had to instead quote it and add on to it, adding another comment to the bug and sending out yet another e-mail to everybody on the CC list.
> A patch was cooked up in October 2011 (comment 124), a year ago, Actually, Yuta submitted that patch in March 2011 (comment 116), and it only received attention eleven months later. > appears dead in the water. Another comment that appears to be patch-related > (135) was made a month ago and has yet to be replied to. (I must confess, > though, that I find this comment hard to make sense of.) Although it's highly offtopic for this bug, this blog post will help you understand the process for accepting patches: http://lpsolit.wordpress.com/2012/05/15/how-to-require-high-quality/
(In reply to Joe Greenman from comment #137) > P.P.S. Please excuse me if this comment appears gratuitous, frivolous, or > both. Given the bug's duration and apparent resistance to resolution, my > ultimate hope in making it is to focus a bit more attention on it. This kind of comments is indeed useless as you are not the first one to blame developers that such or such feature or bug is the most important one and that it's a shame that the bug is still not resolved promptly. On the contrary, such comments have the opposite effect as we tend to consider as spam emails coming from such bugs and sometimes don't even bother reading them. That being said: (In reply to Kyle Repinski from comment #138) > I realized that I could have worded my comment better but rather > than editing it I had to instead quote it and add on to it, adding another > comment to the bug and sending out yet another e-mail to everybody on the CC > list. That's one of the key problems already mentioned in this bug: if someone fixes some typos in a comment, it's indeed useless to spam people. But if someone edits half of the comment, then it makes sense to email people again, because that's not negligible. We cannot delay when to send the initial emails just because someone may edit his own comment right after submitting it. But we also don't want to let someone entirely change his comment after emails have been sent, because what you would get in your email would not match what is now really displayed in the bug itself. And if you edit the comment after someone already replied, then the reply may now look inappropriate, which would generate confusion. Typos honestly don't need to be fixed (it falls into the category of "it would be nice if we could do it", but it's not essential). If a more consequent change is required, then posting a whole new comment makes sense. That's why this bug has priority P4, i.e. low priority.
(In reply to Frédéric Buclin) I think, sir, it's safe to say that several of the people who have contributed to this bug over the years don't share your assessment.
(In reply to Joe Greenman from comment #141) > (In reply to Frédéric Buclin) > > I think, sir, it's safe to say that several of the people who have > contributed to this bug over the years don't share your assessment. I think you could be more respectful of people with your comments as frankly they have come across to me as being extremely rude and disrespectful. Although I wish there was an edit function, I don't feel the need to behave the way you are as that isn't the way to get good attention to something, it only draws negative responses and nothing will become of it. After seeing Frédéric's rebuttal I am able to see why the implementation of an edit function would cause more problems than it would fix, so I am just going to let this be for now.
(In reply to Kyle Repinski from comment #142) > After seeing Frédéric's rebuttal I am able to see why the implementation of > an edit function would cause more problems than it would fix, so I am just > going to let this be for now. I don't strictly want what this bug is about - editable comments, but every other related bug seems to end up being duped here, so this is the only reasonable place to discuss what I think are legitimate needs/desires that are not met currently. Use Case 1. Bug is reported. It's a legitimate bug, but has a *woeful* description (aka comment 0) (I'm sure we've all seen examples :-/). After about 50 comments someone writes a stunningly beautiful description of the bug. But 10 comments later no one can see the *good* description, they're left with the original description. Use Case 2. Comment 50 has a great analysis, but then at comment 78 someone points out a flaw. There's no link from comment 50 to comment 78, so people reading the bug may not see it, links from other bugs directly to comment 50 are not up to date with the latest understanding. Use Case 3. An off-topic conversation is held in the bug, making it harder to find the "meat" of the bug. Use Case 4. Soon after entering a comment you realize you accidentally said the opposite of what you meant. "Of course this will be a problem when we implement widgety class". (Oops won't be a problem...) Use Case 5. Type with no impact on content. My concern is once a bug gets "long" (like this one, this looks like it will be comment 143), it's not realistic to expect everyone to read all the comments, so people miss the important comments, the corrections to the description, the correction to a point made 5 comments later and so on. I am ignoring the "spam" implications, email options is somewhat orthogonal I think. What is the fundamental problem? The comment system is trying to do 2 things - capture history (sort of like forum software) and provide a working analysis of the bug. I made one suggestion to solve this at comment 100. There are some other reasonable ideas scattered through this bug, although I think the only patches provided have exactly the problems expressed in comment 140 - there's no obviously right answer if you allow people to *actually* edit comments. One less radical approach would be to allow certain classes of users grade comments, and then comments below some threshold (could be Boolean) would be by default hidden. That does not address what I consider the *biggest* problem - that the description is comment 0, and you can't ever change it. However, I guess that "comment 0" problem could be solved by adding a custom "Extended Summary" field, and using the current "description" strictly as "comment 0", which could be done by customization of an installation, without code change.
(In reply to Peter Jackson from comment #143) > Type with no impact on content. Ironically I meant Typo. This was not a set up - I promise :-).
I believe, the core problem is, that the "mailing list" approach simply isn't very efficient, when the goal is to find out what is relevant and what is not. Mailing lists are great for chatting, but for more serious purposes, I would suggest a Wiki approach - Wikis are a perfect when a topic needs focus: People can refine the Wiki, and bad edits can be rolled back. As a matter of fact, it also works extremely well for sites like stackoverflow to find an answer for a specific problem. So maybe instead of making comments editable, an alternative would be to simply add a Wiki on top of all the comments. Then, everybody could choose to subscribe either to the wiki, or to the comment stream, or both. Ideally, some people would browse through the comments regularly, and update the wiki accordingly. Depending on permission/role management, updating the wiki would be allowed for everybody ("like Wikipedia"), or only for a limited group.
(In reply to Kyle Repinski) > I think you could be more respectful of people with your comments as frankly > they have come across to me as being extremely rude and disrespectful. I respect your assessment and apologize. Matching content to a style that pleases everyone is complicated, and I've obviously failed in this regard. I was specifically referring to the observation made by Mr. Buclin that, "Typos honestly don't need to be fixed ..." Please refer to comments 35, 40, 57, 62, 80, 96, 97, 103, and others that I've probably missed (I only used Ctrl+f: "typo"). They indicate both directly and indirectly that their authors, like me, don't agree that typos don't need to be fixed. I did not mean to be disrespectful. Again, I apologize.
(In reply to Peter Jackson from comment #143) > Use Case 1. >> Bug is reported. It's a legitimate bug, but has a *woeful* description (aka > comment 0) (I'm sure we've all seen examples :-/). That's pretty common, right. :) But when we have correctly identified the root cause of the problem, we already have several additional comments asking the reporter to give more information about the issue, or ask QA to try to reproduce, and then developers jump in and manage to identify what the problem is. If we were suddenly editing comment 0 to reflect all the discussion into a single comment, this would make all these subsequent comments obsolete, which would make the reading of the bug pretty confusing. So we agree that editing comment 0 in this case is not the right approach. What could be done in this case, and some Bugzilla installations have done it already, is to have a custom text field which contains the current state of the bug, with the correctly identified root cause and the solution to fix the problem. This text field could even contain references to the relevant comments in the bug. This way, you would most of the time (unless you need all the details) only need to read this text field and ignore all the comments. Admins are already free to create such a custom field. > Use Case 2. > Comment 50 has a great analysis, but then at comment 78 someone points out a > flaw. There's no link from comment 50 to comment 78 What we do in this case is to add to the status whiteboard e.g. [see comment 78 for the description of the problem, and comment 122 for a solution], or something similar. Each team manage bugs as they want, but that's what we sometimes do in long bugs. > Use Case 3. > An off-topic conversation is held in the bug, making it harder to find the > "meat" of the bug. Instead of editing/deleting these comments, we plan to implement a different approach for such comments, see bug 793963: the idea is that users being members of some "privileged" group are allowed to tag comments, and once a comment gets the tag "spam" or "obsolete", it is hidden/collapsed by default. So only relevant and neutral comments would still be displayed by default, which would decrease what you need to read. We could also imagine a "important" or "highlight" tag which would make such comments more prominent. > Use Case 4. > Soon after entering a comment you realize you accidentally said the opposite > of what you meant. "Of course this will be a problem when we implement > widgety class". (Oops won't be a problem...) > > Use Case 5. > Typo with no impact on content. Those two cases are the only ones where editing comments would make sense, but again, only if we don't let the author edit the whole comment after emails have been sent. This is the tricky part. > My concern is once a bug gets "long" (like this one, this looks like it will > be comment 143), it's not realistic to expect everyone to read all the > comments, so people miss the important comments, the corrections to the > description, the correction to a point made 5 comments later and so on. This should be addressed by comment tags mentioned above. > One less radical approach would be to allow certain classes of users grade > comments, and then comments below some threshold (could be Boolean) would be > by default hidden. Yeah, that's what bug 793963 is about. > That does not address what I consider the *biggest* > problem - that the description is comment 0, and you can't ever change it. > However, I guess that "comment 0" problem could be solved by adding a custom > "Extended Summary" field Correct. This looks like a better approach to this "initial description" problem.
> Instead of editing/deleting these comments, we plan to implement a different > approach for such comments, see bug 793963 Awesome. Then why not close this bug as WONTFIX if the Bugzilla team ultimately thinks editing comments is bad? The alternative is for the Bugzilla team to clearly articulate the requirements that would lead to the resolution of this bug so that potential contributors can get to work knowing their contributions will be reviewed and considered, thus not wasting anyone's time? Apologies if these requirements _are_ articulated somewhere in this bug. I looked and could not see them. Ironically, if someone had the ability update comment 0 and put the clear requirements there, you would be saving your potential contributors a whole lot of work. (In reply to Frédéric Buclin from comment #140) > That's one of the key problems already mentioned in this bug: if someone > fixes some typos in a comment, it's indeed useless to spam people. FWIW, that is an issue that can be resolved with technology. We have the ability to diff a comment that has been edited, and decide if the change is significant enough to warrant an email.
(In reply to Denis Roy from comment #148) Please see my (extended) posting to the blog you generously alluded to above.
Here is my take on implementing this feature. I originally did something like this when working on Red Hat's Bugzilla and so I have ported the code into an extension. It embeds the comment edit textarea into the comments themselves so no need for a separate page. It relies on javascript being enabled which we could work around if people feel like we need the ability to do this without javascript. It requires a slight change to bug/comments.html.tmpl to add a new hook which I could push upstream separately. Also it updates the longdescs table directly as Bugzilla::Comment does not yet allow for updating thetext column using update(). One plus is it creates an activity log of comment edits so you can see previous versions of the comment and who made the edit. Requires membership in the 'editcomments' group which would need to be created. I will talk to glob about putting this on BMO but comment tagging may make this unnecessary. Enjoy. dkl
Attachment #668485 - Flags: review?(glob)
(In reply to David Lawrence [:dkl] from comment #150) > It requires a slight change to bug/comments.html.tmpl to add a new hook > which I could push upstream separately. this is an upstream bug, not a bmo one. any patches which require upstream changes need to include said changes. > I will talk to glob about putting this on BMO but comment tagging may make > this unnecessary. i don't think general comment editing is appropriate for bmo. i can see some value in admin-only comment editing for extreme circumstances (which we currently address by direct database editing), however i don't think enabling comment editing for a wider audience on bmo will result in a net gain. why is this patch developed as an extension rather than as a normal code change?
I have change mod_cgi to mod_perl, when start apache, I got the error: Starting httpd: Variable "$template" will not stay shared at /var/www/html/bugzilla/editcomment.cgi line 76. Variable "$bug_id" will not stay shared at /var/www/html/bugzilla/editcomment.cgi line 85. and I can not modify the comments any more.
(In reply to shirphy from comment #152) > I have change mod_cgi to mod_perl, when start apache, I got the error: > Starting httpd: Variable "$template" will not stay shared > at /var/www/html/bugzilla/editcomment.cgi line 76. You are using a patch which has explicitly been denied review. We are not going to provide any support for it. Please keep this bug focused on technical aspects.
When run perl checksetup.pl after add the patch, I get the error: Adding foreign key: longdescs_activity.comment_id -> longdescs.comment_id... Adding foreign key: longdescs_activity.who -> profiles.userid... DBD::mysql::db do failed: Can't create table 'bugs.#sql-3c7_81' (errno: 150) [for Statement "ALTER TABLE longdescs_activity ADD CONSTRAINT fk_longdescs_activity_comment_id_longdescs_comment_id FOREIGN KEY (comment_id) REFERENCES longdescs(comment_id) ON UPDATE CASCADE ON DELETE CASCADE, ADD CONSTRAINT fk_longdescs_activity_who_profiles_userid FOREIGN KEY (who) REFERENCES profiles(userid) ON UPDATE CASCADE ON DELETE CASCADE"] at Bugzilla/DB.pm line 654 Bugzilla::DB::bz_add_fks('Bugzilla::DB::Mysql=HASH(0x35e9e40)', 'longdescs_activity', 'HASH(0x5659c58)', 'HASH(0x8154f40)') called at Bugzilla/DB.pm line 561 Bugzilla::DB::bz_setup_foreign_keys('Bugzilla::DB::Mysql=HASH(0x35e9e40)') called at Bugzilla/Install/DB.pm line 685 Bugzilla::Install::DB::update_table_definitions('HASH(0x2187260)') called at checksetup.pl line 199 (In reply to David Lawrence [:dkl] from comment #150) > Created attachment 668485 [details] [diff] [review] Patch to create > extension allowing for editing of comments to privileged users (v1) Here is > my take on implementing this feature. I originally did something like this > when working on Red Hat's Bugzilla and so I have ported the code into an > extension. It embeds the comment edit textarea into the comments > themselves so no need for a separate page. It relies on javascript being > enabled which we could work around if people feel like we need the ability > to do this without javascript. It requires a slight change to > bug/comments.html.tmpl to add a new hook which I could push upstream > separately. Also it updates the longdescs table directly as > Bugzilla::Comment does not yet allow for updating thetext column using > update(). One plus is it creates an activity log of comment edits so you > can see previous versions of the comment and who made the edit. Requires > membership in the 'editcomments' group which would need to be created. I > will talk to glob about putting this on BMO but comment tagging may make > this unnecessary. Enjoy. dkl
(In reply to shirphy from comment #154) > When run perl checksetup.pl after add the patch, I get the error: > Adding foreign key: longdescs_activity.comment_id -> > longdescs.comment_id... > Adding foreign key: longdescs_activity.who -> profiles.userid... > DBD::mysql::db do failed: Can't create table 'bugs.#sql-3c7_81' (errno: 150) > [for Statement "ALTER TABLE longdescs_activity ADD This is usually because the type of integer in one table is different to the type in the other table. brc had this problem with longdescs_activity.comment_id and longdescs.comment_id, but then we are using code written by dkl (when he was a Red Hatter, not the upstream code). -- simon
(In reply to Simon Green from comment #155) > brc had this problem with longdescs_activity.comment_id and > longdescs.comment_id, but then we are using code written by dkl (when he was > a Red Hatter, not the upstream code). Not sure if that is a complement or a complaint ;)
Comment on attachment 668485 [details] [diff] [review] Patch to create extension allowing for editing of comments to privileged users (v1) >=== added directory 'extensions/EditComments' >+package Bugzilla::Extension::EditComments; >+use strict; Missing |use 5.10.1|. Also, please add an empty line after the MPL2 license. >=== added file 'extensions/EditComments/Extension.pm' >+package Bugzilla::Extension::EditComments; >+use strict; Same here. >+sub db_schema_abstract_schema { >+ $schema->{'longdescs_activity'} = { If you edited a comment to remove confidential data, you certainly don't want to log changes, because the confidential data would still be viewable. So I would say that you need at least to be a member of the insidergroup to be allowed to access this table, especially if you edited a private comment. >+sub page_before_template { >+ my ($comment) = grep($_->id == $comment_id, @{ $bug->comments }); I see no check that the user is allowed to view the comment, in the case of a private comment. >+sub bug_end_of_update { >+ print STDERR "comment_id: $comment_id\n"; Remove the debug code. >+ # The comment ID must belong to this bug. >+ my ($comment_obj) = grep($_->id == $comment_id, @{ $bug->comments}); >+ next if !$comment_obj; And you must also make sure that the comment is not private, or that you are a member of the insidergroup.
Attachment #668485 - Flags: review?(glob) → review-
> What is the fundamental problem? The comment system is trying to do 2 things - capture > history (sort of like forum software) and provide a working analysis of the bug This is by far the most useful, insightful comment here. These two functions really should be separable when the situation comes to that. Additionally, there exists the situation of careless or malicious users posting sensitive information. This should be addressed as a separate issue.
dkl: Is there an update to the last patch here coming to address the review issues?
Flags: needinfo?(dkl)
(In reply to Dave Miller [:justdave] from comment #162) > dkl: Is there an update to the last patch here coming to address the review > issues? I will create a new patch for this very soon. As this is not a quarterly goal, I need to finish those up first and then I will be able to get back to this. It is on my short list. dkl
Flags: needinfo?(dkl)
Hello How is the patch going for this
Flags: needinfo?(dkl)
(In reply to David Weir (satdav) from comment #164) > Hello How is the patch going for this Working on this for now as a BMO only customization in bug 936165. dkl
Flags: needinfo?(dkl)
Out of curiosity: Why bmo-only, instead of trying to develop this in upstream by default?
(In reply to Andre Klapper from comment #166) > Out of curiosity: Why bmo-only, instead of trying to develop this in > upstream by default? The reason is pretty obvious: read all the comments from core developers who are against this bug (aka WONTFIX) or who disagree on the way to implement it. Implementing it as a bmo extension means you don't need consensus from core developers. They can do what they want into their own extension.
(In reply to Andre Klapper from comment #166) > Out of curiosity: Why bmo-only, instead of trying to develop this in upstream by default? great question. my understanding of this bug is it's a request for users to edit their own comments; this is not without complications at both technical and consensus levels (as frederic hinted). our requirements are different -- we want a system where only administrators or other suitably blessed users can edit comments - for privacy, security, and anti-spam reasons only. working on this in an extension allows us to rapidly iteration over designs and deploy it quickly onto bmo, while making it available to other sites with a similar requirements long before the next major bugzilla release. hopefully the extension can be upstreamed to deal with the admin-only-edits use-case, however i'm cautious that even if we put it behind security group restrictions in upstream, it'll be enabled for members of 'editbugs', and the expectations of comment editing won't match the implementation.
I have no idea if this is possible, but comment editing should be allowed for at least 1-2 hours after the comment has been made. Although one could argue that "no editing" would result in better thoughtout comments, but I suspect that is not always the case.
For what it's worth, Metafilter has implemented something very much like this as a five-minute edit window. This seems to be a reasonable window for letting people fix grammar and spelling mistakes without derailing or obfuscating lively conversations.
(In reply to Tõnu from comment #169) As far as I'm concerned this would not solve it for us. The bug description is normally the requirement for the bug and requirements change. So commenters should be able to change the description in order for it to always reflect the current requirement. As it is now in Bugzilla one should read all comments to understand the current status of the bug - very error-prone. Other bugtrackers (like Jira) allow to change the bug description.
> As it is now in Bugzilla one should read all comments to understand the > current status of the bug - very error-prone. Other bugtrackers (like Jira) > allow to change the bug description. +1 (In reply to Byron Jones ‹:glob› from comment #168) > our [bmo] requirements are different Everyone's requirements are different. Isn't that why Bugzilla has "params" ? [ ] Allow Admins to edit all comments [ ] Allow Users to edit own comments [ ] Allow Bug Reporter to edit comment 0 Additionally, keeping a history of longdesc changes wouldn't be impossible either. The Internet has changed since 1998. Today people expect to be able to edit content they've authored.
(In reply to Ralf Ronneburger from comment #171) > As far as I'm concerned this would not solve it for us. The bug description > is normally the requirement for the bug and requirements change. So > commenters should be able to change the description in order for it to > always reflect the current requirement. we have an extension on BMO which provides a 'user story' editing field for this purpose. http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/UserStory/ currently configuration happens by editing lib/Constants.pm and it's only enabled in a very limited capacity. (In reply to Denis Roy from comment #172) > (In reply to Byron Jones ‹:glob› from comment #168) > > our [bmo] requirements are different > > Everyone's requirements are different. Isn't that why Bugzilla has "params"? true, but someone needs to do the work and our priorities are weighted towards work which directly benefits us. eclipse is welcome to contribute to work which benefits them :)
(In reply to Byron Jones ‹:glob› from comment #173) > eclipse is welcome to contribute to work which benefits them :) That song sounds familiar. Last year I asked for requirements that would lead to the successful closure of this bug. See comment 148. I haven't heard back.
We now appear to have an extension on bmo that implements the bulk of what everyone's been asking for all along at http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/EditComments/ Works pretty nice, too. Keeps the history around so you can go look to see what they changed if a comment says it's been edited and everything. Is that in a state to be publicly made available? I think at this point I'd like to WONTFIX this bug in favor of "that should be implemented by an extension and not in core", and we point people at that extension when they want it.
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #175) > I think at this point I'd like to WONTFIX this bug in favor of "that should > be implemented by an extension and not in core", and we point people at that > extension when they want it. Actually, a successful resolution of this bug would be to make sure any hooks they had to add to make that extension work get included in core first before we close this.
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #176) > Actually, a successful resolution of this bug would be to make sure any > hooks they had to add to make that extension work get included in core first > before we close this. As for core modules hooks, no additional ones were needed. We are utilizing one template hook that is only present in BMO code currently so I will create an upstream bug to have this one added. Bug 980950 filed. dkl
Given that the two largest public sites (brc and bmo) use this feature, is there any reason the whole extension isn't put in trunk's extension directory, much like the MoreBugUrls extension is? As a brc maintainer, it is rather annoying having to sideport patches from bmo.
Assignee: yuta.sugiura → create-and-change
Depends on: 1031959
I don't think this has any dependency on bug 531269, as that seems sufficiently distinct as to be its own bug (and may already be implemented by an extension anyway). Since the rest of the dependencies we identified here are now completed, does that make this fixed? This is now implemented by an extension, and all of the hooks required by that extension are now in Bugzilla.
No longer depends on: 531269
> http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/EditComments/ Looks promising... Has this content been migrated to git? I don't see an easy "get as zip file" option for the EditComments directory.
This works really well. However, I have one nit. Unless I misread the code, editing comments is based on a global edit_comments_group. I think it would be better if it was similar to bug.user.canedit. This way, I can restrict edit_comment privs to just those bugs who have the associated editbugs privs.
(In reply to Albert Ting from comment #184) > This works really well. However, I have one nit. Unless I misread the > code, editing comments is based on a global edit_comments_group. I think it > would be better if it was similar to bug.user.canedit. This way, I can > restrict edit_comment privs to just those bugs who have the associated > editbugs privs. For BMO it was a policy decision to only allow a select few admins the ability to edit comments and not allow a broader range of people to do so. For other installations, you could just create the edit_comments group and have the 'editbugs' or any other group as a member of it. dkl
(In reply to David Lawrence [:dkl] from comment #185) > For BMO it was a policy decision to only allow a select few admins the > ability to edit comments and not allow a broader range of people to do so. I agree it should be limited to a few admins. But I want further granularity where any user with editbugs for a specific product can edit comments for only that specific product. > For other installations, you could just create the edit_comments group and > have the 'editbugs' or any other group as a member of it. The problem is the code doesn't check which product the specific bug is tied to. So if a person has productA-editbugs and productA-editbugs is in edit_comments_group, that person can edit comments for ALL products, not just productA. I reconfirmed this in my test system.
Perhaps, all that needs to be done is enabling the extension on bugzilla.mozilla.org so that Mozilla contributors benefit themselves. ^.^
(In reply to desiradaniel2007 from comment #187) > Perhaps, all that needs to be done is enabling the extension on > bugzilla.mozilla.org so that Mozilla contributors benefit themselves. ^.^ that extension is already running on bmo, however we will not be granting edit-comments abilities to anyone aside from administrators (we use it to combat spam, and to address privacy and security issues). the bmo plan for wider comment editing involves first allowing changes to be made without triggering bugmail (bug 1062718), and then allowing "ninja edits" -- allow people to edit comments within a short period of time after making that comment, assuming no other changes have been made to the bug. ninja edits would not trigger bugmail. to avoid confusion, please use the "Extensions: EditComments" component in the "bugzilla.mozilla.org" product for any issues with that extension.
(In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment #175) > We now appear to have an extension on bmo that implements the bulk of what > everyone's been asking for all along at > http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/EditComments/ We were looking for this capability but it no longer appears to be available at this address. Can you please tell me how to get this extension?
(In reply to jharmon from comment #189) > (In reply to Dave Miller [:justdave] (justdave@bugzilla.org) from comment > #175) > > We now appear to have an extension on bmo that implements the bulk of what > > everyone's been asking for all along at > > http://bzr.mozilla.org/bmo/4.2/files/head:/extensions/EditComments/ > > We were looking for this capability but it no longer appears to be available > at this address. Can you please tell me how to get this extension? You can get it from our git repo at: http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=summary Specifically: http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=tree;f=extensions/EditComments [github] dkl
I am somewhat loathe to comment on this ancient and controversial bug, but I would like to mention that one of the many proposals in this bug, the "ninja edits" feature mentioned in comment 188, has been spun out into bug 1144473. The most recent discussion here appears to be coalescing around either including EditComments into core, or at least verifying that it works properly with core and including it as a default extension. I'd be happy with either, perhaps leaning slightly towards the latter, just so it is easily left out if someone wants to develop another approach to comment editing as an extension.
(In reply to Antonio Gil from comment #192) > So I find this page and the EditComments extension ... > I am running Bugzilla 4.4.9 on Linux and downloaded last week (Oct 29th > 2015) the extension using David Lawrence info. as per comment 188: please use the "Extensions: EditComments" component in the "bugzilla.mozilla.org" product for any issues with that extension.
So... is there any working EditComments type extension? Most of the links in the comments above do not work anymore. The link in comments 188 and 193 yields nothing, and it is not listed in the known list of addons. The only link that seems to have something is this one: https://github.com/bugzilla/EditComments. Any ideas on whether it would be ok to use that one with 5.0.3? We also use bugzilla for requirements gathering and sometimes you put something in as a placeholder, and then you want to be able to edit it later. And people sometimes accidentally add a comment to the wrong bug. So there are valid cases for wanting to be able to edit comments. I see there are numerous bugs about being able to edit or delete comments (just look at the long list of duplicates for this one), and this is a feature bugzilla did have long ago, so it is sad that it is still missing. If you Google it, the fact that comments are permanent is listed as one of bugilla's limitations. Please consider adding it! Many of us work for companies who use bugzilla but there is pressure to use other tools, so keep bugzilla great! (This is off topic, with one thing our project managers and users have started to love is this: http://almworks.com/deskzilla/features.html. Just because you can edit a large number of bugs very quickly with this productivity tool. It would be nice if the default interface could borrow some of these ideas.)
I also found this one (might be the latest): https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments. (Apparently you may have to comment out line 230 in Extensions/EditComments/Extension.pm, the memcache line, if it gives an error.)
Hmm, these ones do not seem to work with 5.0.3, no option to edit your own comments, and no group that I can see. So is there any known EditComments extension? Thank you.
(In reply to Ben from comment #197) > Hmm, these ones do not seem to work with 5.0.3, no option to edit your own > comments, and no group that I can see. So is there any known EditComments > extension? Thank you. This version is what is being used by BMO but you may need to alter it a little to work with other versions of Bugzilla. BMO is using version 4.2 with a lot of backports from upstream Bugzilla and other customizations. dkl
(In reply to David Lawrence [:dkl] from comment #198) > (In reply to Ben from comment #197) > > Hmm, these ones do not seem to work with 5.0.3, no option to edit your own > > comments, and no group that I can see. So is there any known EditComments > > extension? Thank you. > > This version is what is being used by BMO but you may need to alter it a > little to work with other versions of Bugzilla. BMO is using version 4.2 > with a lot of backports from upstream Bugzilla and other customizations. > > dkl Might help to include the link https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments sorry for the spam. dkl
(In reply to Ben from comment #195) > Please consider adding it! Many of us work for companies who use bugzilla > but there is pressure to use other tools, so keep bugzilla great! A patch that added native edit comments (along the lines of edit comments) would be accepted provided the code was correct. > (This is off topic, with one thing our project managers and users have > started to love is this: http://almworks.com/deskzilla/features.html. Just > because you can edit a large number of bugs very quickly with this > productivity tool. It would be nice if the default interface could borrow > some of these ideas.) A patch adding this feature would also be accepted. We have dearth of able-bodies to do work. I am open to any and all contributions that improve Bugzilla as a product. :)
Does anyone know how to get the EditComments extension working with version 5 by chance. With over 200 comments on this bug and so many duplicates, there is clearly interest. Puh-leese. I am overdue for a nice Christmas present. *smiles*
@Ben: If you have specific problems with some specific 3rd party (bmo) extension, please file bugs in the issue tracker for that extension or ask in a support forum. This task is only about providing that functionality in the upstream Bugzilla core codebase. Thanks for your understanding!
@Ben: For the record, I'm using the EditComments extension Dec-2014 snapshot with Bugzilla 5.0. As Andre commented, recommend filing a separate ticket. Also take a look at bug 1265774
Are you just using https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments, unmodified? Did you have to configure any settings as far as you know?
(In reply to Ben from comment #204) > Are you just using > https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments, > unmodified? Did you have to configure any settings as far as you know? I used the version from Dec-2014. I don't know if the latest changes still work with Bugzilla 5.0. As for settings, you need to grant folks to the editcomments group. For further questions, please file a new ticket under the "bugzilla.mozilla.org" product, Extensions:EditComments component.
We do not need an extension. There needs to be a default, simple way to edit your own comments that is obvious and clearly exposed in the UI. With proposed patches already attached and 81 votes, this needs to be implemented in the entire system. Simply put an 'Edit' button on all of your own comments where the 'Reply' button would be.
To be absolutely clear, the code in EditComments is part of bugzilla.mozilla.org. The next major release of Bugzilla is going to be based entirely on the code that runs bugzilla.mozilla.org, including EditComments. Using EditComments is precisely the behavior that the nascent Bugzilla 6 will have.
So far, I have not seen any simple way (e.g. button) that allows you to edit comments on bugzilla.mozilla.com. If there is any way to edit your comments, it needs to be clearly shown or otherwise made to be less complicated. Does a new bug need to be filed for the b.m.o product to do this? If it already exists, I would appreciate if someone would direct me to it. EDIT: Sorry, I was not aware of how extensions work in Bugzilla. EditComments, as it is in the process of being implemented on bugzilla.mozilla.org, works really well and actually does align with what I wanted (see Comment 206).
I'm having a really hard time getting this to run on 5.0.3. It *seems* to install and run, but doesn't do anything useful. https://bugs.eclipse.org/bugstest/show_bug.cgi?id=458889 I've checked out various revisions, specifically 2e2981d25c185fde56f29c7aed4e3e6bba50039e https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments
We are successfully using the EditComments extension with Bugzilla 5.1.1. The trick was to use the cece2106ee33d4aacae139510a3953cc92828069 commit from the bmo repository and make sure the edit_comments_group param is not blank.
got it going eventually, using 5.0-stable i.e. 5.0.4 i.e. 460c246 you have to make sure that JSON::RPC is installed (0.96 cpan JSON::RPC did the trick), that JSONRPC is *NOT* installed (1.0something), that you create a group named edit_comments in the Administrative panel, that you then *enable* that group. i did notice that there is the rather stupid intent to deprecate JSONRPC in bugzilla, as "XMLRPC is good enough for anybody". this would be a serious mistake. XMLRPC was designed 12 years ago by an idiot who wanted to get himself onto the SOAP technical committee. he didn't even bother to add the ability for parameters to be NULL. JSONRPC on the other hand works extremely well, can pass lists, classes and objects, is based around javascript so is *extremely* efficient for browsers to implement, and if you have access to both a json encode/decode library and a standard http get/post handling library, an entire server implementation can be done in 20 lines of python (50 if you would like to add error handling). this extension - the ability to edit comments - is actually really really important. consider the case where it is necessary to create a series of bugs (say 20 inter-dependent ones) where you wish to create STUB bugs as it's a hell of a lot of work to spec out the bugs *AND* create a complex set of inter-dependencies. with this extension you can COME BACK AND EDIT THE FIRST COMMENT OF EACH BUG LATER. WITHOUT this extension you have a dumb-looking "this is a stub comment" hanging around in each bug in the bugtracker... forever. without this extension if you make spelling mistakes it is impossible to correct them. there's 15 duplicates of this bug. it was first created 20 years ago. it works. what is the hold-up in including it into the next commit?
(In reply to lkcl from comment #211) > what is the hold-up in including it into the next commit? Whatever the reason is: With this feature the gap between Bugzilla and Atlassian would be a big deal smaller. With the feature we might have stayed faithful to Bugzilla, but currently we are moving to Atlassian.
TL;DR: This feature will be available in Bugzilla 6 coming (hopefully) later this year. The current EditComments extension has a big issue: users in the can_edit_comments group are able to edit anyone’s comment, which will be a headache for admins. In Bug 1484892, I’m modifying the extension to allow editbugs users to only edit their own comments, while insiders are allowed to edit any comment and hide revisions in case it contains any sensitive info. Another issue regarding UX: the current implementation requires you to submit the entire bug form to update a comment. It’s confusing, so Bug 1484892 allows to just save the comment in Ajaxy fashion via API, just like GitHub, Facebook or whatever. I’m happy to finally solve this bug, which was mentioned in https://bugzillaupdate.wordpress.com/2018/08/26/happy-20th-birthday-bugzilla/ 😄
Depends on: 1484892
Version: unspecified → Harmony
Thank you Kohei! We really need this feature in bugzilla. Sometimes someone accidentally makes a bad typo or something in a comment or adds a comment in the wrong bug, this will help with that. Also if you can edit comments, you can use it to keep track of all sorts of things. For now we find and edit the comments via MariaDB which is a little painful, but it is a well known work around used for this.
If all goes well with the b.m.o implementation of this (bug 1484477), will it be included in Bugzilla in general? That is the impression I get from Comment 207.
Flags: needinfo?(dylan)
Yes, this will go upstream with Bugzilla 6 (but not later this year). See my comment 213.
Flags: needinfo?(dylan)
Can the extension at https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments be used in bugzilla 5.0.4? Just put under Extensions, run checksetup, and then go and configure it somewhere under admin?

If I understand correctly, this will be a standard feature in the next major bugzilla release (finally). Please don't take it out yet again, lots of people need and want this, for good reasons. I think the latest version lets admin control it, so people who do not want it, can turn it off there.

Can the extension at https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments be used in bugzilla 5.0.4? Just put under Extensions, run checksetup, and then go and configure it somewhere under admin? Does anyone know?

220 comments, we are trying to set a record for the number of years and comments to get an issue in! laughs

(In reply to Ben from comment #219)

If I understand correctly, this will be a standard feature in the next major bugzilla release (finally). Please don't take it out yet again, lots of people need and want this, for good reasons. I think the latest version lets admin control it, so people who do not want it, can turn it off there.

Can the extension at https://github.com/mozilla-bteam/bmo/tree/master/extensions/EditComments be used in bugzilla 5.0.4? Just put under Extensions, run checksetup, and then go and configure it somewhere under admin? Does anyone know?

It is unlikely this will work in 5.0. Even though it is an extension in implementation we consider it a core and required feature.

As for this being 20 years old, that is because the people driving bugzilla development now are new.
The mistakes of the past are not our mistakes and we are working hard to fix them.

Attachment #668485 - Attachment is obsolete: true
Attachment #516092 - Attachment is obsolete: true
Attachment #512100 - Attachment is obsolete: true
Attachment #14032 - Attachment is obsolete: true
Attachment #13871 - Attachment is obsolete: true

I would seem that this bug can finally be closed out - we now have a glorious edit button.

If we could let Kohei do the honours, please.

Flags: needinfo?(kohei.yoshino)

Since this has already been solved in the current Bugzilla trunk (bugzilla.mozilla.org) that you’re on, we can safely close the bug now.

Upstream users: sorry to have kept you waiting, but this feature will be definitely a part of Bugzilla 6.0 along with other UX enhancements including a fresh theme and Markdown support. While we still have to figure out the ETA, the end is near. Let’s celebrate the modernization of the 20-year-ish-old enterprise software! 🎉

Once Bugzilla 6.0 is shipped, we’d be able to merge most components under the Bugzilla and bugzilla.mozilla.org products and triage all the open bugs we have.

Status: NEW → RESOLVED
Closed: 25 years ago → 6 years ago
Flags: needinfo?(kohei.yoshino)
Resolution: --- → FIXED

Fabulous! Looks like the 6 release will have tons of nice new features, including this one. But I see no news or plans around a date for the 6.0 release on here: https://www.bugzilla.org/releases/. Any idea when 6.0 may get released?

This year probably :) (Q2 or Q3 would be great)

(In reply to Martijn from comment #228)

/edit
And still does. It still takes half a year!
I want it on the Firefox issuetracker. What do I care which bugzilla that is? Just put it on there.

And for Thunderbird...

Sylvestre, is there any particular reason why editing comments is not activated for regular users of BMO, not even for a limited timespan after posting comments here on BMO? This is making everyone's life unnecessarily hard, every day...

Flags: needinfo?(sledru)

https://bugzilla.mozilla.org/show_bug.cgi?id=1666041 (my original bug about lack of editing option in TB and FF BMO)

Thomas, please open a new bug for this request.

Flags: needinfo?(sledru)

Or comment in bug 1666041 if its matches your expectations!

(In reply to Sylvestre Ledru [:Sylvestre] from comment #234)

Or comment in bug 1666041 if its matches your expectations!

naah, it's much more hilarious to continue a conversation on a 3-digit 22-year-old bug that, despite being closed, hasn't actually been activated / enabled, when there's 1.6 million other ones in front of it. teehee ;)

This is my point, please open a new bug for request the feature to be enabled.
Bug 540 is fixed. Enabling it for a different set of people is a different discussion.

Restrict Comments: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: