Hey all,
We're using https://docs.atlassian.com/software/jira/docs/api/REST/7.6.1/#api/2/auditing-getRecords to pull audit records out of Jira and send them on their way to elasticsearch. While we can reduce the retention to 1 month and the next time we ship logs just get records since the last pull and wait until records just roll themselves off the database, I'd prefer to be able to purge the log. Have looked through the API docs and there doesn't appear to be anything obvious.
Wondering if there's any undocumented magic anyone happens to know about that could help in this situation?
CCM
You are correct that the Jira REST API does not document any way to delete entries from the audit log. Unfortunately, even when trying to look through the undocumented, private APIs, there still does not appear to be anything in Jira that can do this.
I extended my search to see if perhaps there was a plugin/app in Marketplace that might provide this kind of functionality, however I still go not find anything here either.
The only thing I could think of is that if you happen to be on Jira server, (you can't do this on Cloud), what you could do would be to:
truncate table audit_changed_value;
truncate table audit_item;
truncate table audit_log;
I would not recommend doing this while Jira is running. There are likely other caches that would be corrupted by removing content from these tables while Jira is up and running. But in theory, this is safer to do when Jira is stopped, because on startup all the previous database caches are getting recreated anyways.
I realize this might not be ideal because this becomes a database administration task to follow and not really a programmatic task in Jira to do to achieve this.
Also, before you make changes to a Jira database like this, it's always a good idea to create a backup. I don't believe there is any harm to clearing the contents of these tables while Jira is started, but I honestly have not done this myself yet, so it is possible there are other ramifications I am unaware of yet.
Hey Andrew,
Appreciate you spending the time on looking in to options further. Give the outage requirements for the truncated and no other options, i think we will test out relying on the monthly retention/rollover in the system and make sure we’ve extracted the data we need before then. Will significantly reduce the rows in the database still.
CCM
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.