I am interested it there is a security setting that I missed or if a plugin exists for the deletion of History records under the Activities Area of the View Screen. I was hoping that it would ast similar to the deletion of Comments but I didn't see anything in the Permission Schemes.
The reason for having this capability is the possibility of entering data(either proprietary, classified, embarassing, insulting, etc.) in a field that shouldn't have been. I can edit the issue to change the value but the history still displays the Old Value.
Is going to the database directly my only choice?
Thanks in advance!
No, you have to do this in the database. I've not seen any plugins that would solve the problem either.
Although I have done this a couple of times, it's been quite rare, but I've only really worked in media and financial fields, where the data, widely shared, was not particularly public. I imagine it could be a lot more important in public systems.
Sorry, I should also have said - I wouldn't recommend deleting the changes. The way changes are logged is complex, you'd need to hit the tables changegroup and changeitem for each change, and then think about whether changegroup needs deleting and so on.
If you do want to delete bits of the history, I recommend that you only *update* changeitem. Replace or remove the sensitive stuff (on the odd times I've done this, I've said something like "senstive information removed by admins"). That saves you needing to think about changegroup, it's quicker and easier, and you won't end up with users saying "Hey, why isn't my change logged".
Also, if you do mess with SQL, the procedure is
The stop and start is *mandatory* or you could damage something quite badly. The backup isn't worth skipping. The re-index is very important because if someone put in "I hate windows" and you redacted that in the database, it'll remain searchable in the index, issue navigator, reports, downloads etc, until a reindex replaces it...
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)
I ran into a similar situation (where the Tech Lead decided to grab everyone's attention by putting 1000 as the SP for a few stories). Fortunately, that team had not moved those stories into a sprint (not sure why any team would put such an estimate into their sprints during planning to begin with), so I cloned the stories and then deleted the originals. The cloning does not carry over the history as it starts its own thread. After replacing the stories in the backlog, and deleting the old ones, the reporting went back to normal.
I would assume there might be some ramifications if the stories had been put in a sprint, but again - I doubt you would have done this considering the estimate.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot