Excellent , When is the ETA for 2.4? We are on Confluence 2.2 and would like to upgrade to a version that has this fix.

Ah, good news!

This IS a major issue. Here's why:

1.) Bugs in the interchange between rich-text format and wiki markup format frequently insert spurious nbsp escape characters in bad places. For example, it can ruin URLs by dumping a nbsp near the end of a URL. If someone subsequently clicks on one of these URLs, they get a 404 error, rather than the intended site. This is, of course, a bug that should be fixed in its own right. However, in the meantime, our workaround is to edit pages whenever this bug strikes, to manually fix the URL. BUT (and here's the problem) if the bug strikes in a comment, you can't fix it.

2.) WORSE: If you copy the material from a comment, to place it somewhere else (eg to incorporate it in the main text of a page) links inside that material frequently don't get copied properly. They stop being a hot link and just turn into raw (unlinked) text. The workaround to this problem is to switch to wiki markup format before doing the copy. Copy and paste of wiki markup text seems to work a lot better than copy and paste of rich text. That requires you to start editing the old material first. But for comments, you can't do this. Bummer. As a result, one of the major features of wikis fails - the ability for someone to easily consolidate material from several different sources into a more definitive document.

Users of the trial Confluence Wiki we've put in place are (understandably) complaining more and more about this. I'm hearing words such as "immature product", and I'm coming under pressure to look for a better solution.

Can anyone point me in the direction of better workarounds, or let me know when fix(es) will be available?

FYI, Adaptavist plan to add this as a feature to a future version of our Builder theme for Confluence, hopefully sooner rather than later as one of our clients might be paying us to bring the implementation date forward.

The issue for editable comments in JIRA is JRA-1100.

This feature is not currently scheduled to be implemented in Confluence.

As for a workaround, there's no simple ones as far as I know. You can edit the database and reindex (as described for JIRA on JRA-1100), or you could write a Confluence theme & plugin combination that provided the necessary functionality.

How is it that this issue hasn't been implemented in the two years that this case has been open? Is editable comment functionality going to be included in any future releases of Jira? If so, which ones? Is there a work-around for those of us with users that complain about not being able to edit their comments constantly? Someone please let me know. Thanks!

If a comment is edited (ie. modified date != creation date) then the comment should show a "Last edited by <whoever> on <date>" even if there isn't versioning of comments.

The user that created the last comment should be able to modify (or delete) that comment. I think this would be enough in 90% of the cases (where the user wishes to fix a mistake on the comment just entered).

In this case, the difficult issue of replies/versioning (mentioned by Mathew and Geoffrey above) does not arise.

There is a setting in Global Configuration (in administration console) to switch on threadded comments.

We just started an eval of Confluence 2.2.5. Editing comments has been the number one request from my people. Number two is threaded comments/replies.