In March 2007 the Atlassian community created two suggestion tickets to Atlassian that there is a need for change logs when users edit the comments field. This was a change that was introduced at that time and people quickly noticed that for compliance reasons during audits, there has to be a trace of changes made to a comment and what changes were made.

The problem as described back in 2007

Problem Definition

JIRA-1100 introduced editable comments. This is great. When our security officer reviewed the feature he wanted access to the change history, which would be important in the event of a security audit. It appears that there is no way to view comment history.

Suggested Solution

The ability to view comment change history. Ideally, this would be implemented such that a new permission was added 'View comment change history' so that its implementation could be configured at the site level.

How Atlassian handled these tickets

On October 13th the first ticket, which is for Cloud, was closed for this request, after 17 years (!) with no action taken. You can see the ticket here: https://jira.atlassian.com/browse/JRACLOUD-12400

This was followed up with a corresponding closure of the ticket for Server and Data Center a few days later on October 17th. That ticket can be found here: https://jira.atlassian.com/browse/JRASERVER-12400

This is bad for all forms of audit or control of content

Not only is this a devastating blow towards companies that need this to maintain audit trails for what happens inside a ticket or task, but it is also one of the many reasons why you should never use Jira as a requirement tool. Without the ability to actually trace what happens in a ticket or task, you can never use it in any form of legal context as the content is not tracked with change logs.

It is a bit strange that Atlassian do not want to implement this as this is already in place for Description and pretty much any other field that exist in Jira. It seems it is ONLY the comments field where this is not added (please correct me if there are other fields). So why is it so hard to implement for comments?

One thing that is being referenced is that there are permissions related to comments and because you have comments internally and externally there could be situations where you do not want the original content to show in a change log. This makes no sense to me because the change log already should have this built in because there are other areas that also have permissions connected to them, and they don't seem to have any issues.

It is not hard to add permission data to content such as a change log to ensure the changes are seen only by people that should be able to see it. It is also not difficult to add another permission for who can see the change log for comment changes.

Atlassian is just not interested in changing unsexy things like comments as they want to build new cool features instead. This is quite obvious from the many tickets never being touched that relates to basic functionality that should be standard in an enterprise platform.

No traceability for comments, so what?

I see this comment a lot in those tickets as well. Why do we need to keep track of what is written in the comments anyway, who cares? Well, there are actually many use cases for this.

For Jira Service Management it is not uncommon that support agents, or customers send sensitive data in comments, even though they should not. This could for example be a password or a token used in a product. If there is a breach, and it leads to a legal situation, then obviously you need to be able to see if a support agent is at fault or not. If all you see if that a comment has been edited, but not in what way, this can cause an issue.

Yes, you can dig this up in the mail logs and customer notification logs, but only if they are still available and if it is possible to retrieve them. In some cases a ticket might even be moved to another project if there is no proper escalation process and then the content of the ticket changes, and it is even harder to find the emails and customer notifications will not even exist for that ticket in the new project.

It can also be that you have claims of insult or inappropriate behavior in the comments and if you are in a Jira project and this was some time back, then it will be hard to find in the logs and to know what was actually written.

In some cases people are using comments as a requirement field (yes, I know that this is borderline insanity, but it happens). In that case you might have serious issues with contracts if the requirements change with no traceability of what or when. This is also true if you use comments for approvals (again, very bad practice) and a hundred other things that take place in the comments.

What can you do to mitigate this?

If you really need this then you are basically forced to either buy an app or be very creative with automations and custom fields.

There is an app called Issue History for Jira that is listed in the comments in one of these tickets and with this you can see all kind of activities that happens in a ticket. This app is not exactly free, and it is a bit puzzling to me as to why this is not bought up by Atlassian and placed into the core Jira product.

If you want to take the "free" route then you can try to create an automation that save comments on create and also make new saves based on comments edited. It would probably be best to add this to Assets since you will basically see a doubling of content and then any changes on top of that, so you will have quite a lot of entries added. Just consider the new consumption based pricing for Assets which will make that solution as expensive or not more compared to an app...

Conclusion: Atlassian does not care about legal requirements, unless they have to?

Ignoring a real legal requirement that many users have is bad, and it does not look good on a company that claim to be an Enterprise solution. Leaving this open for 17 years and in that time they must have reworked the comments functions dozens of times and still they did not put any perceivable efforts into adding a basic functionality such as traceability for customer communication?

I am sorry, but that is just sloppy and a blatant disregard for legal requirements that their users face globally today.

This feels like a clear breach of Don’t #@!% the customer.