See http://answers.atlassian.com/questions/75537/how-do-i-find-if-an-issue-has-been-deleted for details on how to see information in the log and a plugin for audit information.
See https://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions on Delete Issues permission and the recommendation from Atlassian to "Think carefully about which groups or project roles you assign this permission".
Hennings is absolutely correct - delete really does mean delete. The only thing you can see is a "hole" in the numbers in the project (which may also mean "issue moved")
There's a plugin which can audit deleted issues to some extent (it logs who, when and key) and you can keep the "issue deleted" emails too, but that's it.
One other option to build on Hennings "restrict delete to only a handful of users" is to have a "waste bin" project - let people move issues in there if they really want rid of them.
It makes perfect sense, that a deleted issue really is deleted – its contents gone.
But should not the act of deletion itself still be recorded in
changegroup tables, though?
On a related note, can someone suggest a clever SQL query, which would list holes in the
jiraissues table? Standard SQL preferred, obviously, but even a MySQL-only variant would be most appreciated... Thanks!
No, you've missed the point - it contains a key reference to the issue by its id. So when you ask "which issue did you delete", JIRA has to say "I dunno, it's gone"
When it retains users, it's just the login name. So the answer is "all I can tell you is a user who logged in as <username>", not "I dunno because there's no data to look up". (Note also, it's bad practice to delete users who have done things)
So when you ask "which issue did you delete", JIRA has to say "I dunno, it's gone"
At least, the record would remain for any future audit. Joining the
changeitem tables, I could say, who deleted an issue and when.
When it retains users, it's just the login name.
Yes. And a samilar kind of record could be added upon issue deletion. The
FIELDTYPE could say something like "Deletion", the
FIELD would be "Issue", the old value – issue key
(FOO-1). The existing data-model does not need changing.
Some time later JIRA could provide an interface to it as well, but that's secondary...
Sorry, I'm not saying it should not be logged, just that this table is completely the wrong place to do it - because the table is tied to issues. Which you've just removed.
I'd put it in a dedicated table, or even just the "issue moved" table with an empty "to" field - that's enough data to tell us it was deleted.
Here's an Oracle Database select statement to at least list the "holes" within a project (i.e. those items which were deleted).
Of course it does not list the content of the items, as that is gone.
define PROJECTKEY = 'LCH'; -- Project Key select '&PROJECTKEY-'||n.nr deleted_items from jiraissue ji join project p on (ji.project = p.id and p.pkey='&PROJECTKEY') right join (SELECT LEVEL nr FROM dual CONNECT BY LEVEL <= (select p.PCOUNTER from project p where p.pkey='&PROJECTKEY') ) n on (n.nr=ji.issuenum) where ji.issuenum is null order by n.nr;
Note: The statement joines the jiraissue table with a "virtual number-table" from 1 to pcounter (max-number) on the project.
On other databases, such as MySql you may need to create a table with a number column and fill it with numbers from 1 to the project-counter (number of last created item).
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
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