Hi ayakovlev@atlassian.com , agree to former comments. This is far more a QA hygiene topic than a feature request.

Question: how many votes of user feedback is necessary? 759 for now seems a pretty high number. thx

Another dissapointing decision by Atlassian ^TM

I think I have lost the count already... that's too many basic features that they have 'decided not to proceed' with. At the same time, licence fees are higher every year, and the investment is harder to justify every year.

Might be looking for a replacement app in the future.

Hi Rudy Slaiby,

stating: "We’re currently focusing on other areas of the product and prioritize those that provide the most value to the majority of our users "

and at the same time ignoring nearly 1000 votes on this issues for now over 17 years is a impudence!

Formerly one of Atlassian pillars was "Don't f..k the customer". This meanwhile seems to be reversed meanwhile by Atlassian!

To me this seems like another case of: Do not offer core features -> Thrive on plugin subscriptions.

This is an audit log flaw (could change a comment saying "im okay with it" to "over my dead body" without any trail other than "has been changed")

Todays decision by Atlassian to ignore this issue despite it being easy to fix is extremely disapointing.

Not to mention that this ticket has been open for 17 years and has the support of 759 voters (assuming an average licence of 1000 users, 759'000 users affected and 58-129Mn in licencing fees alone (software - JSM) + the cut Atlassian takes on marketplace plugins.

The literal billions of dollars spent by the 759 voters here over the last 17years should get us a developer for 3 days to add history to comments on Jira or Atlassian buying off one of the plugins that solves this audit trail issue and incoporating it.

This is a feature that is becoming more necessary as time goes on - are there any plans to implement?  You already carry out the exact same logging with the description field, so including the comments only makes logical sense.

Jean-Pol Landrain added a comment - 19/May/2016 6:14 PM

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 business. That's insane.

We are in 2024 and that's still not possible. This linked to new legal requirements, along with a new licensing model that forces us to move to the Cloud or to use more expensive Datacenter licences for our Atlassian products, are the main reasons you've lost a large european customer. We were using multiple instances of each of these products : Jira, Confluence, BitBucket, Fisheye/Crucible. We are currently in a migration process moving out of the Atlassian products. You've lost a long time customer, about 20 years. So good bye, Atlassian. It was a nice journey, we can only blame you for not listening to your customers anymore.

+1 

The edited comment is flagged with an "edited" tag, yet the History/Activity log fails to provide any details on the changes made. The sole evidence lies in the email notification indicating that the project admin conducted the edits.

This discrepancy raises significant concerns, as it jeopardizes the reliability of JIRA for maintaining an accurate audit trail or supporting any form of attestation. Is there a vital aspect I'm overlooking? Rather than a mere suggestion, this discrepancy appears to be a critical bug that demands urgent attention.

+1 for the ability to see the change history of edited comments

813cab5e75b8 I agree, it should. But it doesn't and never did and as you see how old the Issue is, it probalby never will... so why complaining. Hundreds of companies seemed to have found a way to handle it. The strategy of Atlassian is clear. They will only implement something, if it CVE relevant or a feature they can sell or make more money with. So the main focus of Atlassian is to improve the Add-On platform, because there they make the money. So if there will be no hack of a Addon vendor, there will never come a solution for it. At least not for self-hosted applications. So why spending time complaining about it? We even have older issue requests here with higher amount of votes... so the strategy of Atlassian should be clear. They don't care about their on-premise customers. They just care about the addon platform and cloud customers.

a7e9ce396f68 So you want to tell me that your auditor checks hundreds of comments on hundreds of issues? Why are comments at all relevant for an audit? It's just comments... Where can I find the history of my facebook comments?
The thing is I am trying to tell you that you should use the tool in the way it was made for, not in a way you want it to be that it is not... If you are not happy with it, then it is probably the wrong tool. We never had problems with audits, since the relevant info about decisions, etc. is stored in according specified fields. Comments are just like a conversation to help pointing out risks or ideas. Do you audit also your conversations in meetings or may be at least your meeting minutes? Then you should rather do your comments in the tool where you do your meeting minutes.

From an application developer's perspective, we always keep history tables behind any table that can be updated.  It's very important that this information be kept for auditing purposes.  Not only for outside auditors, but even for those entering the comments since they may not even remember the history of an issue that may be pertinent for how things changed over time.   Our JIRAs often contain requirements information which can change as the project develops.  Sometime it is necessary to understand the history to justify why a piece of code was changed.  Without the history, this may not be possible.  I can even imagine a legal issue where the history can protect the innocent.  The bottom line is that if it can be updated, then it should have the ability to keep history.

Hi Michael, what a useless comment from you!

Editing a comment, at least your own comments, is essential to be able to correct typos etc. But a auditor i always asking if at some point of time any information of a issue was different to the current information (no I don't mean here added comments, I mean changed comments. And restricting the functionality of Jira for such essential functionality like comments to ensure that the system is auditable is no solution. So let the users of the product decide if the need history on comments or not and not Atlassian. For other tools this is really a no brainer, so why should it be for Atlassian? Comment history needs not to be part of the index, and that a comment was changed is already today available, so why not also the previous content of the comment.
Together with a purge function (as it was introduced more then a decade after the launch of confluence for page history with the latest LTS Version) would allow the user to decide when comment history could be removed form the system and free the occupied space.

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 ?

"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.

It's hard to fathom the logic behind NOT having this - or why you'd change from fixed comments to editable in the first place if you don't consider it part and parcel of doing so.  This is not a feature request.  This is a basic requirement of any core communication system to be reliably auditable and have a full transaction history.

For now we're just deleting the permission to edit/delete comments - and by the way, in this case please stop your system for pinging us from doing so.  It's entirely inappropriate that you think this 'feature' (bug) warrants an explicit permissions check in your code.  You should have spent the energy coding that on a simple audit log instead!

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.