How to modify issue history? (Jira Cloud)

[Marco Eckstein]

There are situations when you may need to modify issue history, e.g. when you needed to quickly do a simple import that did not include history, but later realize that it would be possible to program a more sophisticated import that retains history.

How can you do it in Jira cloud? This question has been asked before for Jira Server, and there the only way seems to be to modify the underlying database, which Jira cloud users cannot access.

I have some ideas about this, but please let me know what you think.

Current state of Jira Export/Import

• Jira can export:

  • XML + attachment files (apparently a whole database backup)

• Jira can import:

  • XML + attachment files (the whole database backup), though it does currently not work for me.

  • CSV (including creation date, but apparently not history)

  • JSON (apparently with history)

  • Trello (no creation date or history)

  • Other Jira instances

Potential options for fixing history

• Rewriting history via API or GUI

  • Apparently not possible
    

• Backup, rewrite history in the XML backup files and restore

  • Probably viable

• Re-importing

  • Not an option because then I lose the more recent history

• Export recent history via API to JSON import format, merge with old history, re-import (issue keys will change)

  • Probably viable, but must check that re-imported issues will have the same links as the to-be-deleted issues.

Note that Atlassian is looking to completely overhaul the backup/restore experience. I wonder whether they will change the backup format from XML to JSON.

[Nic Brough -Adaptavist-]

The only viable option on your list is "backup, hack backup, destroy current site by importing hacked backup"

Jira is an issue tracker, the whole point is to track changes made to the issues.  Destroying the history of an issue is the antithesis of what it is for.

I've only ever run into one case where editing (not destroying) the history of an issue was a valid thing to do, and it's not a case I'd ever expect the authors of software to code for.  Plus it's now fixable without resorting to database hacks in Jira and Confluence.

[Marco Eckstein]

destroy current site by importing hacked backup

With destroy, do you just mean overwriting (as would be expected), or are you implying the backup format is so difficulat to understand and modify that it will easily get corrupted?

Plus it's now fixable without resorting to database hacks in Jira and Confluence.

What do you mean? Editing the history is possible? If so, how?

[Nic Brough -Adaptavist-]

The import will destroy all the data currently in the site.  If, for example, you took the backup on Monday, edited it, and imported it on Friday, then you would destroy all the data that has been added or amended since Monday.

No, as I said in my answer, the history is not editable (without database hacking).  I was talking about the one case where you should be amending history records, but you don't need to do it in the history any more because of some of the recent changes to the way Jira stores certain data.

[Marco Eckstein]

I was talking about the one case where you should be amending history records, but you don't need to do it in the history any more because of some of the recent changes to the way Jira stores certain data.

Can you please tell me what that case is and what these changes are?

[Nic Brough -Adaptavist-]

It doesn't matter because you don't need to edit the history to make the change any more.  If you run into it, you'll be looking to make changes elsewhere now anyway.

[Wojciech Wardaszko _HeroCoders_]

I actually find editing  - sepcifically censoring PII - in JSM ticket history quite important and sorely missed feature. 

Whenever we get a "forget me" request from our customers, we need to clone the issue, edit-out all the PII in the comments and then delete the original issue. Not the best user experience and Zendesk, Dixa, Helpdesk - all have it sorted out, but not JSM.

[Nic Brough -Adaptavist-]

You may be misreading the laws here.  People do have a right to be forgotten, but various states have different rules on auditing, and the "right to forget" is very much over-ruled by "the need to know who did what".

In many states (including Germany, which is the example I use all the time because it is very strict), it remains illegal to destroy any personal information tied to certain types of activity.

As a local example, it is illegal in the UK to "anonymise" any taxable operation for an individual person or registered company for between 6 and 18 years.  "Forget me" is utterly irrelevant, HMRC have an absolute right to demand knowledge of ownership, and they can put you in jail for not recording it and keeping the records.

Zendesk, Dixa, and Helpdesk are doing what Jira does - hiding stuff, not deleting.  If they were deleting, we would be reading about them being in courts.

[Wojciech Wardaszko _HeroCoders_]

Sorry to say that, but the way I see this matter I think one of the things you mention apply to a typical support request scenario in Atlassian ecosystem. We do not handle invoices - that's handled by the Atlassian Support Team. 

I do not believe any type of activity that is legally obligatory to track are in scope for our support operation, and we cannot store personal data against the will of the owner of that data without a very good legal reason.

The way it is now, I do not have an easy way to actually grant the request to be forgotten even if I was legally obliged to do so, and I believe it should be addressed.

I do not want to delete history, I want to be able to anonymize it.