We are moving a project from a secure zone to a public zone. Some of the issues previously had sensitive data in them, but have modified for public consumption. We would like to clear the history/changelog, so the previous changes cannot be seen.
We have the project on an interim server, so we can pretty much do whatever.. I've just not seen a clear answer on how to perform this.
Only way of doing this is to drop the records out of the history using SQL. You'll need to find the stuff you want to destroy in "changeitem" and then check the associated "changegroup" record - if it has no changeitems left, then you should remove that too. For comments, jiraaction is the table to look at. I would not recommend touching anything else though, I don't know them well enough.
Normally, I warn people off SQL tinkering, but in this case, it is moderately safe as long as you keep the changegroup/item relationship above clean. The history is not directly used a lot and there aren't associated counters to update for deleteion. You really do need to do the standard Jira/SQL routine though - shut down Jira, backup the database, prove you can restore it, run your SQL, restart Jira and do a full re-index.
Nic, would you recommend certain documentation to get queries from for this, or a certain command to clear the tables?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry, I was half understanding what I was typing. I was essentially asking if you were using "DELETE FROM" or "TRUNCATE" or "REPLACE", whathaveyou. I ended up doing this with "DELETE FROM" and it worked well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Not sure what you mean by "certain documentation to get queries from this". If you delete the history data, it's gone, dead, never to be recovered, so there's no queries you can run on it after you destroy it.
I'm not sure about "certain command" either. I would like to jump on the "clear the tables" clause - you absolutely do NOT want to do this. The aim is to destroy some historical data, not the entire system. So you run deletes in SQL to remove the lines you know you don't want.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
If you have script runner plugin you can run the following. replace ABC-1234 with your own issue key. Don't forget to test it in a test env first.
import com.atlassian.jira.issue.Issue; import com.atlassian.jira.component.ComponentAccessor def issueManager = ComponentAccessor.getIssueManager() Issue issue = issueManager.getIssueObject("ABC-1234") def changeHistoryManager = ComponentAccessor.getChangeHistoryManager() changeHistoryManager.removeAllChangeItems(issue)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Er, that won't actually work - this question is about a version where those calls are different.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I've just run this script from Ravi in 7.1.8 which works (thanks!).
I was just wondering if there is a way to specify a particular entry from the change history rather than all of the change history?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for sharing Ravi, this worked for my instance and saved me a large headache of having to explain to users why they will need to stop work for a period of time while I take out the data.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm, as far as I know, there really isn't any method to do this except to perform some queries on the database directly to erase them. However, as you might expect, this method can be a tad risky, as there could be quite a number of tables linked to each other that could affect this.
I'd recommend that yuo work with the DBA for this, and make sure you always have a backup on hand, in case anything goes awry.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.