|
Also requested in
Also requested in
This is very important for us too. Especially when using the email CommentHandler many times our customers reply with no ">" marks in the emails. This results in the whole email conversation being added as comment to the issue every time the customer replies to our queries. It would be very nice to be able to cut the extra lines from the comments. I would want the ability for normal users to be able to edit their own comments and for administrators to be able to edit anybodys comments.
I've had a myriad of users ask me for this functionality so it would be great if we could see it in a near-future release.
One of the key problems with being able to edit comments is the discontinuity. If someone replies to a comment, and then that comment is contextually altered, the reply would seem strange ... eg:
Bert - I would really like this, but fish would seem strange. Although a strange conversation, the messages make sense in the context they are in ... if bert was to edit his message contextually the comments might read like this: Bert - I would really like this. and now bill's comment seems out of the blue. This sort of scenario is already possible through the deleting of comments. Replying to a comment that is then deleted makes it very disjointed. I propose something more along the lines of confluence's history of a page, but for comments. Where by you can see what comments used to be - including the option to show deleted comments (highlighted as such), or view the whole comment tree from a certain point in time (a la cvs). Permalinks could then be selectable between seeing the latest version of that comment, or that exact version of the comment. I dont think diff's between comments are important, but others might. Just a thought ... The comment should be editable as long it is the last comment in the list. This would avoid the inconsistency problem. Many discussion forum programs do it this way, and it seems sufficient.
Alternatively, rather than limiting it to the last comment, allow version control of comments in a similar (possibly more restrictive) way to pages. This would allow people to see the original comments and how they were edited, so that they could evaluate whether they were edited to change the content majorly / minorly, or whether it was just to correct grammatical / spelling errors.
Here's one to mince your minds a little - what about allowing the changes to have comments, like the suggestion to allow modifications to pages to have hidden comments, only shown against the revision (like CVS commit comments). The question comes then, should those comments then be editable ... personally I dont think thats required to start with, but a recursive system of commenting in this way would exceed the functionality of any other system I can think of - for the better. If these options were all switchable in an advanced config area, this would allow greater flexability and allow people to use confluence how they like. If you dont like the advanced functionality, dont use/enable it. Being able to adjust the Visibility of a comment after it has been posted would be nice too.
I agree with Dan (http://jira.atlassian.com/browse/JRA-1100#action_20385
 ), that hiding is preferable to deleting or editing comments. It would also allow a user to correct mistakes in a comment they make (by hiding the comment and re-commenting) without mucking up the audit trail.
From a UI point of view, perhaps the "Comments" tab header could show if there are hidden comments eg: "Comments (12 hidden)" and the All tab could show the hidden ones. Comment hiding sounds a bit like a fork of this issue. Should we start a new issue, or would people accept Dan's proposal as an alternative to editing? I think issue
Could this be done via a theme or plugin?
Brendan,
This is unfortunately not possible through anything short of directly customising JIRA at the moment. We have a daily meeting looking at project issues. I just want to have a chance to keep from looking like an idiot.
Mike,
You can always edit the data in the database directly if you are desperate. You will most probably need to bounce the apllication and re-index after. Cheers, Any ETA on implementation of this? The request has been open since 2003 - plenty of time to implement I would think..
 Hi Chris,
As this issue is unscheduled, we do not have an ETA for it. Anton Hi Bojan,
At the moment we do not have any specific dates for this issue. There are other issues that are currently more popular than this one and we are working our way through them. We do realise that this issue is important and we are keeping it in mind. Unfortunately, I cannot be specific about the implementation date. Anton My users are asking for this as well.
The continuity question should be dealt with by using a permissions scheme allowing for users to be able to 1. edit their comments no matter what, 2. edit their comments if they are the most recent ones, 3. not be able to edit comments at all. In other words, let the administrator of the Jira installation/project decide how to deal with continuity. Regardless of the scheme chosen, an issue should reflect the fact that it's been edited. If possible, it would be nice to be able to view the history of the edits. I don't want to get disliked ... but I must confess that I'm really looking forward to this feature.
It took me a while to put together a proposal for the mailing list and I added comments to the appriopriate JIRA issues - unfortunately I did not check the URL twice - so everyone who clicks on the URL faces an error. No way to correct the URLs one more thought on this... a recent issue had a client report that the change history showed sensitive information from a comment that was previously deleted. Same problem applies here. If I want to edit a comment to prevent someone from seeing something they shouldn't, then it's not going to help if they can easily show Change History to see the unedited version.
This is causing great frustration in our user community as well. Please see this treated with priority.
Bulletin board software deals with all these issues already, why not have a look at how they handle it?? I think it would be good to just let the JIRA admin make the choice to enable/disable comment editing.
Chiming in with my vote for this issue. I like the idea of the ability to edit the comment if it is your comment and it is the last comment in the comment chain. An administrative-level preference to control comment editability though would be the best IMHO, with the choices being:
Comment Behavior (radio):
Also, if discontinuity is concerned, how about a database-level relationship from one comment to another? This would allow your view to markup a comment that has been changed, in that when a comment is edited, a new comment is actually added to the comment chain right after the originally edited comment. The original comment would then be greyed out with some visual indication that the following comment was a revision to the older comment. That, combined with possibly an auto-hide (but with toggle-ability) of the old comment seems like a viable solution. Is there any real plan to implement this feature? It's 3 years old. We really need it.
Antonio,
There is a plan, however, I cannot provide an implementation date at the moment. We are hoping to get this done. Anton If you're struggling to get a date for the ability to edit comments, then an interim solution for us would be to separate out the "delete comment" permission from the "Delete Issue" permission.
Then I'd be able to allow anyone to delete comments.. without allowing them to delete issues... We are using the email-handler to add issues in Jira.
It is an easy way make users add comments on issues. However, email adds unnecessary information (signature, disclaimer links, ...). I do ask the question of Antonio Pellez again: We are currently reviewing this product for our development team and after a small amount of internal testing we have come across this issue.
Deleting comments and re-adding the corrected version is not a great work around for us, having the option to edit a comment, your own comment at the very least would be really handy. The pressure is mounting.
I would like to add that especially since you may enter comments with wiki-markup the importance of this issue increased even more. In case you did anything wrong entering your wiki-markup and forgot to preview first you won't have a chance to fix the markup.
After three years this is still not solved. What a joke. I checked the "votes" and it is in the top 10. The only conclusion (after considering how many other features were added in this time) is that 1) this is never going to be fixed and 2) the line about "other issues" with more votes is a lie 3) the legendary service is not so great.
Too bad that once I post this comment, the only way to change it would be to hack the database (that is until we can finally edit these things). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Resolved
Major
Ability to Edit Comments
JRA-1100.