Status: Closed (View Workflow)
Atlassian Update – 1 June 2018 Hi everyone, We’re glad to announce that we’ve added new events to the audit log to let you track more activities in Jira with the 7.10 release. As you may have already noticed, 7.10 was released this week, and you can download it here . With the new events, you can check who: created a new issue type enabled/disabled one of the global settings - “Allow unassigned issues” In addition, as suggested in JSWSERVER-12017 , we’ve added events for board changes (board created or deleted) and sprints (sprint deleted). This update meets the original requests made in this suggestion, and I’ll mark it as resolved. We’ll continue to work on the audit log events, tracking any further requests in this suggestion, which already includes changes to custom field contexts, resolutions, and global system settings. Here’s an article about Auditing in Jira applications , where you can find a complete set of events currently tracked in the Jira audit log. You can also read about other features in Jira Software 7.10 in the release notes . Kind regards, Katarzyna Derenda Product Manager, Jira Server
We have many Jira Administrators - at least one per project.
In a way, this is due to a missing level of administration (
JRA-3156) - but regardless of that fact, its necessary to know which administrator did what & when - we need to have an audit trail of Administrator actions. In some cases, we need to have notifications - or have additional information in existing notifications detail who the administrator was that performed this action.
Currently, the problems we have experienced are:
- (done as of 7.5.0, see example screenshot-1.png) A user is created, but we dont know by who. Sometimes, we see a user that isnt meant to exist e.g. "testUser" - but we dont know who to contact to get rid of it.
Sometimes the user themselves have a problem logging on, getting access to their project etc - and it would be useful for them to contact the administrator that created their account rather - therefore it would be useful to have this info in an audit trail, so we can find out who it is - or better still, have this information in the email sent out (
- (done) A default notification scheme is changed - affecting all projects - and we dont know who did it (we want to know who did it so we can ask them not to do that again)
- (done) A global custom field is added (usually by mistake) - affecting all projects - and we dont know who did it (We want to know who did it so we can remove it - and ask them not to do that again)
- (done as of 7.10) A new issue type is added - affecting all projects - and we dont know who did it (we want to know who did it so we can discuss using an existing issue type - or discuss the addition of a new type so that it makes sense to more projects)
- (done) A user we dont know about is given jira-administrator priveledges. Given the fact that this new user may not know very much about how to administer Jira - and they can go on to do the things mentioned above, then we need to know about this. We need to contact the administrator who did it and ask them not to do it again. We need to contact the new jira-administrator and make sure they know what they are doing!
- (done as of 7.10) Someone turns unnassigned issues "on" and all of a sudden Project Leads stop getting notifications for new issues on their project. We need to know who did it, so we can break their legs .
These have been the main ones that have bitten us.