bbab0fcfeb91 How on earth would you develop a tool supporting all special cases the user have, just because they are not willing to use the tool as it was meant to be. You can also hammer a screw into the wall...

It's about convenience for the users and using all features of Jira while allowing full history auditing in some special use cases.

b2286d261fd1 Comments is no Jira field, even it looks a bit like one. But in the end it is a separate table holding the comments as entries for an Issue in the database. So it is a total different handling than for field log history... Even I don't get why it needs to be, since comments are a completely different approach to Jira fields.
If you have such important information in a comment, you should better think of storing it in another textfield, where the relevance becomes clear. I mean how can you figure out what comment is important and what not, when you have like 100 comments at an Issue? So even if you would have a history there, how would that be helpful at all?

bbab0fcfeb91 I don't see a problem for audits here, I must say... You would just need to adapt your permission scheme in order to not allow editing/deleting own/all comments. So you would allow only new comments. With this you have your history and avoid prior comments to be modified/deleted.
Also you should probably re-evaluate the way you use comments and if such audit relevant information should be stored in comments at all or if you better use a standard field or another solution for it.

We require this for audit reasons.

This feature helps to understand if there were changes to past comments . Not sure how this is different to maintaining the history log of description .

Definitely need that .

I see now we have a paid addon to enable this feature https://marketplace.atlassian.com/apps/1211639/comment-history-for-jira?tab=overview&hosting=datacentere, just wondering if this is the reason to disable it ?

2ad15a11324e added a comment - 27/Sep/2021 5:06 PM
 

Hello Prijanka,

sorry for waiting so long.

The Line Breaks were missing. Below are the correct Lines.

...
import com.atlassian.jira.issue.util.IssueUpdater
import com.google.common.collect.Lists
def issueUpdater = ComponentAccessor.getComponent(IssueUpdater)

...

"So if you commented on an issue something which included content you did not wish a third party to see, then changed it later to be more palatable to a wider audience, you would not wish that earlier version to be visible to the wider audience."

So comment histories should only be available to the comment creator, ticket creator (in which the comment was made), and the admin, right?   Still good enough to audit deceptive changes.

I strongly support the request for this feature.

What is the explanation to log the changes of the issue description in the History, but not log the editing of comments?

Please consider this request in the near future.

4bd7935b303e Hardly an explanation, history entries could simply keep the visibility level. It would take more time to implement, but isn't impossible

one of the reasons that Comment change history is not implemented is that Comments (unlike fields) may have a security privilege associated with them. If you have comment that you edit you would need to have the security context saved with the history item. So if you commented on an issue something which included content you did not wish a third party to see, then changed it later to be more palatable to a wider audience, you would not wish that earlier version to be visible to the wider audience.
 
Highly recommend to reenable this.

If they finish this within fifteen years from right now (26 May 2022 at 3:17PM), I'll give you $1. Make that three-fifty.

Hey Team - this issue has seen 4 different US presidents. Is there any progress being made to improve visibility on changes made on comments? 

I must say it is already unbelievable that this feature does not exist, however, it is unacceptable that this is a known issue for 15 years now. 

Any insights would be appreciated! 

Unbelievable...

Really unbelievable, we just also hard hit this problem / missing history while a audit. It really was not accepted bay the auditors that our answer was, there is no way to show you the history of a edited comment.

Shame on Atlassian that a 15 YEARS old issue that is in addition already 4 Years in the long term roadmap still not solved. In what time frames Atlassian is thinking?

Dane Kanter is 100% correct.  There has to be auditable change tracking on all changes to Jira issues, especially free-form comments that can be seen by customers and other employees.  What if a legal action is taken based on some public comment by a customer/employee that was later edited to remove their bad behavior?

Hello team,

"import com.google.common.collect.Listsdef issueUpdater = " package is not defined. Could you please help me with it? It is declared in the comment delete script which provided above.

I'm with you. It is on Atlassian to solve this bug asap.

For our Company I implemented these Scripts in ScriptRunner for Jira.

Custom listener
Projects: All projects
Events: Issue Comment Deleted

// 
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventType
import com.atlassian.jira.issue.comments.Comment
import com.atlassian.jira.issue.history.ChangeItemBean
import com.atlassian.jira.issue.util.IssueUpdateBean
import com.atlassian.jira.issue.util.IssueUpdaterimport com.google.common.collect.Listsdef issueUpdater = ComponentAccessor.getComponent(IssueUpdater)
def previousComment = event.params?.originalcomment as Comment
def comment = event.comment// Pre-condition: Both comments exist
assert previousComment// Create the ChangeBundle
def changeItemBean = constructChangeItemBeanForCommentEdit(previousComment, comment)
def issueUpdateBean = new IssueUpdateBean(previousComment.getIssue(), previousComment.getIssue(), EventType.ISSUE_COMMENT_EDITED_ID, ComponentAccessor.jiraAuthenticationContext.getLoggedInUser())issueUpdateBean.setChangeItems(Lists.newArrayList(changeItemBean) as ArrayList<ChangeItemBean>)
issueUpdateBean.setDispatchEvent(true)
issueUpdater.doUpdate(issueUpdateBean, false)// Generate the the ChangeItemBean for an Edit based on the old and new comments
def constructChangeItemBeanForCommentEdit(Comment oldComment, Comment newComment) {   
    String oldBody = getCommentBody(oldComment)
    String newBody = ""
    return new ChangeItemBean(ChangeItemBean.STATIC_FIELD, "Comment", oldBody, newBody)
}// Comment below generated by Atlassian within their source code
// Check the level of the comment, if the level is not null we need to override the comment
// This is necessary as part of JRA-9394 to remove comment text from the change history for security (or lack thereof)
def getCommentBody(Comment comment) {
    final String groupLevel = comment.getGroupLevel()
    final String roleLevel = (comment.getRoleLevel() == null) ? null : comment.getRoleLevel().getName()
    final String actionLevel = groupLevel == null ? roleLevel : groupLevel
    if (actionLevel != null) {
        return "This comment has the security level '${actionLevel}'. For privacy reasons, no changes will be listed here"
    } else {
        return comment.getBody()
    }
}

Custom listener
Projects: All projects
Events: Issue Comment Edited

// 
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventType
import com.atlassian.jira.issue.comments.Comment
import com.atlassian.jira.issue.history.ChangeItemBean
import com.atlassian.jira.issue.util.IssueUpdateBean
import com.atlassian.jira.issue.util.IssueUpdaterimport com.google.common.collect.Listsdef issueUpdater = ComponentAccessor.getComponent(IssueUpdater)
def previousComment = event.params?.originalcomment as Comment
def comment = event.comment// Pre-condition: Both comments exist
assert previousComment && comment// Create the ChangeBundle
def changeItemBean = constructChangeItemBeanForCommentEdit(previousComment, comment)
def issueUpdateBean = new IssueUpdateBean(comment.getIssue(), comment.getIssue(), EventType.ISSUE_COMMENT_EDITED_ID, comment.getUpdateAuthorApplicationUser())issueUpdateBean.setChangeItems(Lists.newArrayList(changeItemBean) as ArrayList<ChangeItemBean>)
issueUpdateBean.setDispatchEvent(true)
issueUpdater.doUpdate(issueUpdateBean, false)// Generate the the ChangeItemBean for an Edit based on the old and new comments
def constructChangeItemBeanForCommentEdit(Comment oldComment, Comment newComment) {   
    String oldBody = getCommentBody(oldComment)
    String newBody = getCommentBody(newComment)
    return new ChangeItemBean(ChangeItemBean.STATIC_FIELD, "Comment", oldBody, newBody)
}// Comment below generated by Atlassian within their source code
// Check the level of the comment, if the level is not null we need to override the comment
// This is necessary as part of JRA-9394 to remove comment text from the change history for security (or lack thereof)
def getCommentBody(Comment comment) {
    final String groupLevel = comment.getGroupLevel()
    final String roleLevel = (comment.getRoleLevel() == null) ? null : comment.getRoleLevel().getName()
    final String actionLevel = groupLevel == null ? roleLevel : groupLevel
    if (actionLevel != null) {
        return "This comment has the security level '${actionLevel}'. For privacy reasons, no changes will be listed here"
    } else {
        return comment.getBody()
    }
}

+1

It's hard to imagine any organization that doesn't use a ticketing systems' comment feature to at some point convey pertinent business information. It's also hard to imagine a ticketing system that has every possible communication ever about a ticket/issue/project mapped into some structured field; there will always be a need for unstructured data that goes into comments.

So as long as this remains to be part of any business process, it should be auditable. I 100% guarantee you there have been people fired, or not fired, for things they have said or done or haven't done in their ticketing system of record. But if you can't prove what was even said, your employees may be taking actions based off an incomplete picture and you've opened yourself up to potential legal/HR issues even by not having this. This is not just some "nice to have" at all, it's an absolute necessity. And yes you can disable comments as a horrible workaround, which is what some orgs I know of have had to do because of this one lacking feature. And that then is a strike for a missing feature (inability to edit comments) against Jira vs every other system out there where these things are auditable.

Re: comments are just comments... it is not a field, it's multiple entries, it's for conversation... store information in real Issue fields to have a history for it.

No, comments need to be correctable.   I work in an operations environment.  Occasionally people have brain farts and leave out the "no" in a sentence or say "no" instead of "now".   Also, people occasionally/accidentally say something wrong in a comment, where that action can be very dangerous (ie., can cause an outage or loss of data).  You need to be able to add a "later edit" to the comment saying, "This is wrong.  See comments below for the correct procedure"   

Even if you correct bad comment in a later comment, if there are lots of comments on the ticket, it's very easy to not realize that an earlier comment is dangerously inaccurate.   And, because of various auditing requirements, you need to have an audit trail of these comment edits.

And yes, you have to be careful not to abuse the comment editing process, but most of the time, the only reason someone goes back to edit a comment, is to correct a typo or add a later edit saying "Ignore this comment, it turns out it's totally wrong.  See below."

@Michael Aglas, I am with Venkatesh Prasad on this. If comments were not important why bother typing them in jira? These are valuable discussions that allow traceability of why certain decisions where made.

@Michael Aglas : I do not completely agree with you. The information that goes into the comments section of the issue is not junk information. It is a meaningful discussion happening about a story or a bug.

For example, I heard from a friend of mine working in another organization that one of the team members in their team had mentioned something in the comments section as to what was agreed during their previous discussion.

Many in the team had read that comment as soon as he wrote it. Next day, this team member realized that he had mentioned something he should have not mentioned in the comment and so he went ahead and edited the comment and changed its contents.

Now, there is no way we can get to know what this person initially wrote in the comments.

When others in the team asked him about that, he argued that he never wrote anything like that and he edited the comments section due to spell mistake in one of the words.

This is just one of the examples.

Assume a scenario where a person had put some info in the comments. He then edits that info by removing few lines and adding few new lines. Later if he realizes that he wanted to access the first comment he wrote, then there is no way we can get that as Jira will not record this history.

I definitely feel this is a Bug in the tool. I worked in Rational ClearCase and Rational Collaborative LifeCycle Management tools and they all have this feature. Its only Jira which lags this feature.

This is certainly not a Chat tool, but it certainly is a Version controlled tool and the version control features should not be limited only to certain fields in Jira. Comments is a very important field which should record the version controlled info.

comments are just comments... it is not a field, it's multiple entries, it's for conversation... store information in real Issue fields to have a history for it... use permission settings to disallow editing/deleting comments -> Jira is no chat tool, is it?

The previous issue tracking system I utilized had the ability to show all audits/changes to comments. (Who changed what, when, Old value, New Value, if it was deleted).

This is a highly needed capability for Jira Cloud.

@Mathew Harkins,

Jira already logs this information without any Custom  Listeners (left column - old value, right column - new value, no value, deleted):

But in any case, the way you described would be the way to go!

Kind regards, 

Pablo Culebras
Atlassian Solution Consultant
codecentric AG - Atlassian Platinum Partner 

Great solution! It shows me again how much I enjoy working with Codecentric.

I can recommend the "Workflow Essentials" app from marketplace.

You can expand on Pablos great solution to also create Change logs for deleted comments.

Create a new listener using the code below and specify the "Comment Deleted" event and this will then log the deleted comments in the same way as his original solution logs the edited comments.

Here is his code modified specifically for processing comment deletions: :

// code placeholder 
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventType
import com.atlassian.jira.issue.comments.Comment
import com.atlassian.jira.issue.history.ChangeItemBean
import com.atlassian.jira.issue.util.IssueUpdateBean
import com.atlassian.jira.issue.util.IssueUpdater
import com.google.common.collect.Listsdef issueUpdater = ComponentAccessor.getComponent(IssueUpdater)
def previousComment = event.params?.originalcomment as Comment
def comment = event.comment// Pre-condition: Both comments exist
assert previousComment// Create the ChangeBundle
def changeItemBean = constructChangeItemBeanForCommentEdit(previousComment, comment)
def issueUpdateBean = new IssueUpdateBean(previousComment.getIssue(), previousComment.getIssue(), EventType.ISSUE_COMMENT_EDITED_ID, ComponentAccessor.jiraAuthenticationContext.getLoggedInUser())
issueUpdateBean.setChangeItems(Lists.newArrayList(changeItemBean) as ArrayList<ChangeItemBean>)
issueUpdateBean.setDispatchEvent(true)
issueUpdater.doUpdate(issueUpdateBean, false)// Generate the the ChangeItemBean for an Edit based on the old and new comments
def constructChangeItemBeanForCommentEdit(Comment oldComment, Comment newComment) {   
    String oldBody = getCommentBody(oldComment)
    String newBody = ""
    return new ChangeItemBean(ChangeItemBean.STATIC_FIELD, "Comment", oldBody, newBody)
}// Comment below generated by Atlassian within their source code
// Check the level of the comment, if the level is not null we need to override the comment
// This is necessary as part of JRA-9394 to remove comment text from the change history for security (or lack thereof)
def getCommentBody(Comment comment) {
    final String groupLevel = comment.getGroupLevel()
    final String roleLevel = (comment.getRoleLevel() == null) ? null : comment.getRoleLevel().getName()
    final String actionLevel = groupLevel == null ? roleLevel : groupLevel
    if (actionLevel != null) {
        return "This comment has the security level '${actionLevel}'. For privacy reasons, no changes will be listed here"
    } else {
        return comment.getBody()
    }
}

 -edited because I was too excited for this solution and didn't check the execution status of my changes.  My previous submission produced the results I wanted, but also generated exceptions.  This new version cleans up the exceptions so the code runs cleanly.

Have you assessed any potential performance impacts by adding this listener?

Hi everyone, 

I developed a Custom Script Listener for those using Adaptavist's ScriptRunner for Jira. By following the instructions below these lines, each time a comment is edited, a listener will generate a new entry in the change log. It also takes into account the Security Level / Group / Role restrictions of a comment.

Step-by-step guide

As a Jira Administrator using Jira 7 or higher:

1. Click on the Admin Cog -> Manage apps -> Script Listeners (on the left sidebar)
2. Once the page loads, click on Create Listener -> Custom Listener
3. Add a meaningful Note such as: This listener adds an entry to the Change Log every time a comment is edited.
4. Under Project(s) select All Projects (or choose those Projects, where this Listener will take effect)
5. Under Events select the Issue Comment Edited Event Type
6. Copy the following code under the Inline script form field:

   import com.atlassian.jira.component.ComponentAccessor
   import com.atlassian.jira.event.type.EventType
   import com.atlassian.jira.issue.comments.Comment
   import com.atlassian.jira.issue.history.ChangeItemBean
   import com.atlassian.jira.issue.util.IssueUpdateBean
   import com.atlassian.jira.issue.util.IssueUpdater
   
   import com.google.common.collect.Lists
   
   def issueUpdater = ComponentAccessor.getComponent(IssueUpdater)
   def previousComment = event.params?.originalcomment as Comment
   def comment = event.comment
   
   // Pre-condition: Both comments exist
   assert previousComment && comment
   
   // Create the ChangeBundle
   def changeItemBean = constructChangeItemBeanForCommentEdit(previousComment, comment)
   def issueUpdateBean = new IssueUpdateBean(comment.getIssue(), comment.getIssue(), EventType.ISSUE_COMMENT_EDITED_ID, comment.getUpdateAuthorApplicationUser())
   
   issueUpdateBean.setChangeItems(Lists.newArrayList(changeItemBean) as ArrayList<ChangeItemBean>)
   issueUpdateBean.setDispatchEvent(true)
   issueUpdater.doUpdate(issueUpdateBean, false)
   
   // Generate the the ChangeItemBean for an Edit based on the old and new comments
   def constructChangeItemBeanForCommentEdit(Comment oldComment, Comment newComment) {   
       String oldBody = getCommentBody(oldComment)
       String newBody = getCommentBody(newComment)
       return new ChangeItemBean(ChangeItemBean.STATIC_FIELD, "Comment", oldBody, newBody)
   }
   
   // Comment below generated by Atlassian within their source code
   // Check the level of the comment, if the level is not null we need to override the comment
   // This is necessary as part of JRA-9394 to remove comment text from the change history for security (or lack thereof)
   def getCommentBody(Comment comment) {
       final String groupLevel = comment.getGroupLevel()
       final String roleLevel = (comment.getRoleLevel() == null) ? null : comment.getRoleLevel().getName()
       final String actionLevel = groupLevel == null ? roleLevel : groupLevel
       if (actionLevel != null) {
           return "This comment has the security level '${actionLevel}'. For privacy reasons, no changes will be listed here"
       } else {
           return comment.getBody()
       }
   }
   

7. Click on Add in order to save the Listener and you are done!

Screenshots

I hope this little code snippet makes the 512 voters of this issue happy and helps their businesses be a little bit more productive. 

Kind regards,

Pablo Culebras
Atlassian Solution Consultant
codecentric AG - Atlassian Platinum Partner 

As a workaround, I enable notifications for the following events:

• Issue Commented
• Issue Comment Edited
• Issue Comment Deleted

I've tested a similar setup using WebHooks to Slack & Microsoft Teams.

It's not ideal obviously as I'd have to search my email archive system for the issue and its events in question, rather than looking up that history within JIRA itself...

@Venkatesh - Based on my experience to date with Atlassian, there's no profit in it to build a system that has complete integrity, and it might rob someone of the opportunity to sell a plugin and thus save Atlassian from the aforementioned unprofitable fixing of their product.

I have the same issue...

I see this was created back in 2007. Its been 12 years and still no actions. There are over 500 votes and 300 watchers for this issue. What else is stopping you guys from fixing this ?

+1

+1

My comment is edited by third person and history shows that I have added that 'whole edited comment'.

This is not correct.Comments modification should be logged in history.

WOW, what HUGE security hole!Unable to render embedded object: File (  I had no idea there was no auditing of comment edits until I wanted to see something I accidentally deleted myself.  Now, I will have to go find someone who received email on the original comment, which is a big hassle, but livable.  However, can you imagine a malicious user going and wide-scale editing/deleting important comments in a some high priority issues?) not found. Brutal ...

+1.

Adding my +1..

+1
We are waiting for this needful thing in the tracking system

So, 12 month after February 15th, 2018 this issue should have been reviewed.. Would be nice to hear about an update...

Anothet vote.

I really don't think tehy listen to thier customers.

No money in fixing this Adrian, not for Atlassian nor their market partners.

Raised in 2007. Wow. I'd have thought this to be a compliance no-brainer. We also need this functionality in Jira Cloud.

Perhaps the plugin "Comment History for JIRA" (Marketplace-url) could solve the open point for those waiting.

Another vote and another comment.  We've been trying to champion Jira as the tool we use for many of our processes, and working in a heavily regulated industry, this is an absolute must.  You need to be able to audit all the changes.

Please work on this if you think you want to support regulated processes.

Dear Atlassian team, 
I also would like to highlight how IMPORTANT this issues is for us (and I can't see how it cannot be for others). Everything needs to be revision save for us to be able to use Jira as THE IT system for our change management (including test documentation and approval process)... 

paging Dave Meyer

Maybe beating a dead horse but hey...

We'd like to use Jira to track Management decisions which may contain legally binding data, i.e. we need a complete audit trail including comments.

--> Any dev effort on this is highly appreciated.

Sorry Atlassian, to me it looks like you're lost in time way behind presence. There are some requests like this one in here, which should be, no, have to be state of the art of a modern software as you claim yours to be. Instead of changin look and feel or some other quiestionable low priority changes of usability, you should use your ressources to adopt your software to the requirements of the presence.

This is already open since 2007 and a release version is still not set and will not be set in 12 months time... Atlassian, you might as well close it and stop pretending that you value feedback from your customers.

I suggest that if you take 12 months just to think about adding to a longer term roadmap then you are seriously misguided. For my part, I shall be taking the time over the twleve monthe to migrate to something else that meets our regulatory compliance requirements.

As others have said many times, this is a serious issue restricting us from using this application as a System of Record. Fully auditable of everything is crucial when you are...audited. Please increase the priority. Thank you.

Hi everyone,

Thanks for your interest in this issue.
This request is considered a potential addition to our longer-term roadmap.

We'll typically review this request in about 12 months time, at which point we’ll consider whether we need to alter its status.

For the nearest future we've decided to prioritize other areas of the Jira Server roadmap, including:

• Performance and stability improvements
• Archiving projects for improved performance
• Optimising the use of custom fields
• Improving performance of boards

• Improving Jira notifications
• Allowing users to edit shared filters and dashboards
• Mobile app for Jira Server

You can learn more about our approach to highly voted server suggestions here.

To learn more on how JAC suggestions are reviewed, see our updated workflow for server feature suggestions.

Kind regards,
Jira Server Product Management

I find it curious that basic functionality of tracking changes isn't considered to be worthy of implementation.  Why would we be concerned with tracking all other changes but not these specific one?  Especially when the Updated date is affected in the ticket but there is no traceability to what change was made.  These comments are being made relative to the fact that my issue isn't getting addressed as pointed out in ticket SDS-28774.

Hi @patrickb, If you are interested I have a plugin that keeps the history of edited and deleted comments.  It is a paid plugin but if you interested checkout https://marketplace.atlassian.com/plugins/com.redmoon.jira.commenthistory.commenthistory/server/overview

@patrickb it is possible to set project permissions to disallow editing for an audit trail. Just remove the project permissions "edit all comments" and "edit own comments". 

Just ran into this  issue also.  Atlassian is going to have to fix this if you want to play in the Regulated space.  I notice that Comala workflows has guidelines on 21CFR Part 21 but that doesn't do much if the base application can't meet the requirements of simply logging everything that changes on a record.  I am in month 3 of implementing JIRA SD, Core, and Confluence for our highly regulated Pharma environment and this is a show stopper unless I have an option to turn off the ability to edit comments. 

I just came across this suggestion while wondering why I could not see a comment's history... May this be implemented within the next 10 years? 

Editing comments is a wonderful feature, but some people are not blessed with the needed sense of responsibility and there is no easy way to fix that...

10 years passed

I would also vote for this feature as well.

As we get more users making JIRA a core system for Technical Investigations, as already said, the administrators want to make sure the users are commenting.  Otherwise, we might as well prevent "editing comments" altogether if we cannot check how or why the comments are audited.  Jozef's reasoning in handling dispuets is definitely one of those scenarios.

Just some thoughts I wanted to share here:
ticket opened for > 10 Years ? Any reason for removing a "Comment history" feature, care to explain ? Over here some users get into dispute over what they have said in a comment in time and what they have said after editing a comment in time +n. I know that it all goes to email as a notification but, as a JIRA admin I am unable to resolve such disputes thanks to missing feature of seeing comments history. I know the plugin developers like this Comment History for JIRA must make a living but, I remember a version of JIRA where this feature was out of the box which made the JIRA product even more valuable.

I do not get why you did remove this feature. Before it was possible to se all edited comments and descriptions in History. Please putt it back!

I would love to see this added but even without it, JIRA is still a great product. SOX and auditing regulations require us to maintain a history to comments, and in lieu of being dependent on 3rd-Party functionality (nothing wrong with 3rd-Party) we choose to eliminate the ability to delete or edit comments. This was coming from 1800+ user base that was used to being able to delete and edit comments. There was a little push-back initially but most users understood the requirements and now (about a year later) its no big deal. We too will get comments correcting a previous comment but I cant say it diminishes the usefulness of the JIRA.

We license the Comment History add-on, and it works perfectly for this use case. It would certainly be convenient if Atlassian were to absorb it into the main product, but that would increase the cost of JIRA for everyone, including folks who don't want or need comment history. Contrary to most of the sentiment expressed here, I agree with Atlassian's decision not to implement this in the near future. I would rather effort be focused on other issues.

Our very, very large Bugzilla instance did not have comment editing at all, and no one found that particularly burdensome. Certainly, there were lots of follow-on comments that were just corrections to the previous comment, but such comments were infrequent. It's just not the case that the ability to edit comments (and then preserve an audit history of edits) is a necessary capability of a bug tracking system.

When we adopted JIRA, if we had realized that comment history wasn't being preserved, our permission schemes probably would not have included letting users edit comments. When we noticed the behavior, we immediately disabled comment editing, but our users found that really objectionable - they'd gotten used to editing comment. So, that's why we license the Comment History add-on.

Why the hell Atlassian doesn't understand this is both a penalty for existing customers and a blocking factor for potential new customers ? Guys, you are losing busines. That's insane.

Why the hell Atlassian doesn't understand this is both a penalty for existing customers and a blocking factor for potential new customers ? Guys, you are losing busines. That's insane.

Clicking on https://support.atlassian.com/browse/GHS-43016 gives a page with "You do not have permission to view this request"

HI,
security seems to be preventing me from following your link.

But in the meantime: If a third party can do it why can't you just buy it off them and bundle it? That way it doesn't interfere with your development schedule at all.

It seems to be a $ issue as much as anything else..

@Dieter Greiner

We've had the same problem and we had no choice but to turn to a paid plugin. (Would be nice of Atlassian to pick up the tab ).

https://marketplace.atlassian.com/plugins/com.redmoon.jira.commenthistory.commenthistory/server/overview

Due to missing history it is not possible to track down problems caused by editing comments (https://support.atlassian.com/servicedesk/customer/portal/22/JSP-266851)

dmeyer writes:

Currently the top priorities of the JIRA development team are:

3. Improving the UX of key tasks for software teams

I think commenting is the most commonly performed task, i.e. a key task. And in real life typos and worse happen every day, so being able to edit comments is important for the UX. Otherwise the comment history gets cluttered with incorrect info, which needs to be corrected further down.

However, as mentioned before many times an audit trail is required, and often not negotiable for legal reasons.

So I have little understanding that such a key feature is still not even planned 9 years after the issue has been raised.

Its disapointing that Dave Meyer is reporting that this will not be implemeted. Really disapointing. JIRA can't call itself a market leader when the audit facilitites are so poor. Even IBM Clearquest has an Audit package.

Its a shame that there is no real explanation about why this decision has been made. I agree that there needs to be some big improvements made to performance but at the expense of data integrity I think the roadmap is a bit flawed. If JIRA performance is a priority because JIRA is being aimed at the larger organisation then the regulatory frameworks that these organisations work in should be respected too.

I can't see why this isn't being seen as a quick fix and quick win?

Our company develops software for financial institutions. Shortly after our implementation of Jira back in 2008, our program management and audit teams asked us to disable editing of comments because there's no change history or audit trail when comments are changed. When users ask about enabling edits, I refer them to this issue.

After a few initial steps, Atlassian seems to have dropped the idea of having complete audit trails available, even for system administration actions and permission-related changes like role membership assignments. As a result, it's no big surprise that the change history of edited comments is still not implemented. Maybe someday this will change, but it doesn't seem to be coming any time soon.

Hello dmeyer!

Sadly, this will result comments editing feature being switched of at your customer in regulated (safety / security) contexts.
Wouldn't it be as simple as adding a history event to the edit comment action?

Hans-Jürgen

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; unfortunately we don't have any plans to support this in JIRA for the foreseeable future.

Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

Hi there,

We have a post here that provides a detailed explanation of how the JIRA product management team uses jira.atlassian.com and why issues with a large number of votes are not necessarily on our roadmap. We're never able to work on everything at once, and we prioritize based on a number of different sources. Even if we did prioritize our work exclusively by votes on jira.atlassian.com, there are 38 open suggestions above this one.

Currently the top priorities of the JIRA development team are:

1. Performance, especially initial page loads for highly-used pages
2. Reducing complexity of setting up and maintaining projects
3. Improving the UX of key tasks for software teams

Thanks for your patience. Please contact me if you have any questions: dmeyer (at) atlassian (dot) com

Regards,
Dave Meyer
Product Manager, JIRA Platform

I refer to my earlier comment which hasn't been answered:

"So, we have a question. Why is this not on atlassian's JIRA development roadmap?
I suggest that atlassian does not understand how this affects us.

I haven't seen any reasonable explanation for it but If it isn't addressed I will have a strong case for moving on to a tool that can maintain an audit trail.

Many of us are trying to work within a regulatory framework for our products and if there is any doubt about the integrity of data our products may fail to be certified by the FDA, CESG and other certifying bodies. So come on atlassian step up to the mark or we are likely to jump ship."

Its dosen't matter how good you think your product is - its no good for many of us if there is no credible audit trail

This is extremely needed. Please resolve!

The comment from march is a whole lot of nothing. Pointing us to priorities are determined is useless when this issue isn't updated with a planned implementation date/version.

Voting for this one.
This is needed!

Agree with Paul Dillon
The whole point of Jira is the record keeping!

I am a big fan of Atlassian and particularly Jira, but this really should be core functionality. Very poor that it would cost me $700.

How nice of you to drop the price of something that should be part of the core product in the first place.

The Comment History plugin has now been reduced in price for the 50 user price upwards, with the biggest price drops in the upper user levels. This is a permanent price drop.

there are several +5 year issues that could be solved this way, but it's not happening for some reason..
Why would Atlassian buy these plugins or develop them thereselves? The price is going up with or without developping the core product further

I think that a perfect solution all round is that Atlassian get their wallet out and buy the plugin off Redmoon and then give it to us

+1, definitively.

I think that a perfect solution all round is that Atlassian buy the plugin off Redmoon and then give it to us. That way:

1. It takes no time to fix.
2. Atlassian Devs don't get an extra job to do.
3. Customers (like me) are happy
4. Redmoon don't feel like they have been shafted.

Come on Atlassian, please

If the carelessness from Atlassian is done on purpose to make room for the plugin pointed by jan.cornelissen, this would deeply sully Atlassian as a reliable and respectable company.

The other question about the pricey plug in is simply about the provider. How is it supported? Is redmoon a on-man-band? - certainly looks like it.
It is niave to make purchases from companies that could be a flash in the pan or could disapear tommorrow as is the case with many of the plugin and app providers.

My big problem is this: We use Jira to support the development teams on multi-million pound developments. My organisation has 16000 employees and over 1 million online users of one if our systems that we use jira to maintain and enhance. I need to be able to keep an audit trail of 'who told who to do what and when' as it frequently involves significant costs.

Actually I didn't know about the pricey plugin - I looked at it and it would be perfect. difficult getting clearance to buy it though as my boss thinks that the core system should do it anyway.

Maybe the existence of a very pricey plugin 'Comment history for Jira' has something to do with it?
Just thinking out loud.. not (yet) jumping to conclusions..

So, we have a question. Why is this not on atlassian's JIRA development roadmap?
I suggest that atlassian does not understand how this affects us.

I haven't seen any reasonable explanation for it but If it isn't addressed I will have a strong case for moving on to a tool that can maintain an audit trail.

Many of us are trying to work within a regulatory framework for our products and if there is any doubt about the integrity of data our products may fail to be certified by the FDA, CESG and other certifying bodies. So come on atalassian step up to the mark or we are likely to jump ship.

I clearly agree with hjt, this feature request must have a higher priority considering the security and auditing perspective. The ability to change a comment without tracking content history is just useless for any company larger than few peoples. Is Jira a "maybe / almost" tracking software? I just can't believe this has been requested more than seven years ago now, I would like to know the real reason why it is ignored so much by Atlassian.

Let me share my impression that Atlassian is focussing more on

• smaller teams (small enough to ensure oversight of work, so the assignee filter in agile boards is not a top-priority)
• smaller projects (with less issues to be planned, the missing category filter in agile boards and the lack of deep issue copying)
• in smaller companies (i.e. not working so much with user directories)
• in environments with less safety and security driven auditing requirements (comments are left to be the only non-history element)

Sad, somehow. Instead, we see fancy features dropping in, which are nice and comfortable, but do not really solve the real problems in advanced environments. It would be really nice if these could be taken more into account from my and our teams point of view.

My data security are breaking my minerals over this, I really need it addressed also. How many votes, if not 220, is going to be enough? Anyone got any idea?
thanks

We would like to have this ability. We never want a user to be able to go in and edit their comments without being able to see what it used to be. For instance our users frequently add information as comments to the issues. An example would be on a notification to display to customers they might have the wording as 'X' and change it to 'Y' after talking further with the marketing department. We don't want them to be able to make the change without us specifically knowing about it and want to be able to see the history of when that happens. The only option to enable that now (without the pay-for addon that doesn't work with hosted JIRA anyway) is to forbid comment editing and to make them enter a new comment. That clutters up the issue.

I don't understand why this would have any differing security implications than viewing changes to other fields for an issue. Viewing comment history could be a special role that could be assigned to certain groups.

I've just been stung by this issue - it needs to be fixed and soon. It should not be possible to make a change that can't be audited.

Is anyone from Atlassian aware of this issue? Seven years seems excessive, we would need this as well, as we rely on the change history for our integration.