Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-3157

JIRA Administration Audit trail / notifications

XMLWordPrintable

    • 963
    • 832

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Atlassian Update - August 2023

      We are closing this ticket (JRACLOUD-3157) in favour of more specific feature requests.
      Please see full explanation in the comment here.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      Atlassian Update – 14 January 2019

      Hi everyone,

      For Jira Cloud, we have implemented a number of the audit log requests on the original description, including notification schemes and custom fields. While adding additional Jira-specific events to the Jira audit log is not on our roadmap, we will keep this ticket open to announce if new events are added in the future.

      For our cloud products broadly, we are working to add a richer set of audit logs to for Atlassian cloud administration and Atlassian Access features in order to provide better visibility into administration activities across all of our cloud products. We are focused on addressing ACCESS-577, and then expanding into additional insights into Atlassian account changes, app installations, site and billing changes across all the products in use at your organization.

      Regards,
      Dave Meyer
      Atlassian Product Management

      Original request description

      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:

      1. 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 (JRA-2555)
      2. 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)
      3. 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)
      4. 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)
      5. 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)
      6. 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 .
      7. Currently, in the audit logs of JIRA, it does not cover changes done in the screen scheme section, or screens in JIRA Administration. We are then unable to find out who performed changes there.
      8. Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc.
      9. There is no Audit log for the changes to Default "Priority" on the Global Priority Settings. An Admin can change the Default Priority from Medium to Low and the next created Issues take that priority by default.
      10. Audit log doesn't capture "Issue Collectors" that are deleted from JIRA Projects
      11. Currently, the Audit Logs of Jira doesn't cover changes made to the filter. Creating multiple filters, changing the filter owner and modifying filters in the Jira Software. None of these activities is reflected in the audit log
      12. Audit logs does not show changes made by Add-ons. Example custom fields created on addition of TEMPO does not log into Jira audit logs.

      These have been the main ones that have bitten us.

        1. image (23).png
          image (23).png
          57 kB
        2. image-2021-04-22-16-56-27-096.png
          image-2021-04-22-16-56-27-096.png
          223 kB

          Form Name

            [JRACLOUD-3157] JIRA Administration Audit trail / notifications

            Ran Lavi added a comment -

            @Dave, I believe you forgot to mention in your comment the suggestion for point #12 in the original description:

            "Audit logs does not show changes made by Add-ons. Example custom fields created on addition of TEMPO does not log into Jira audit logs"

            This point #12 was added just recently, as result of support ticket JST-895119, and has resulted also in creation of the following suggestion: https://jira.atlassian.com/browse/JRACLOUD-81508.

            I request to make sure that suggestion JRACLOUD-81508. is also mentioned here in the new description and linked to here.

            This is a critical missing functionality.

            The customers are relying on the Jira audit log to reflect the main admin changes done by anybody, including apps. Unfortunately, the audit log simply doesn’t show anything done by the apps.

            This is a huge concern for our customer! And this makes it very hard for them to approve apps for usage. They simply cannot accept the risk of an app that has Jira admin permission, that can do everything in Jira, without ability to monitor it.

            Ran Lavi added a comment - @Dave, I believe you forgot to mention in your comment the suggestion for point #12 in the original description: "Audit logs does not show changes made by Add-ons. Example custom fields created on addition of TEMPO does not log into Jira audit logs" This point #12 was added just recently, as result of support ticket JST-895119, and has resulted also in creation of the following suggestion: https://jira.atlassian.com/browse/JRACLOUD-81508 . I request to make sure that suggestion JRACLOUD-81508 . is also mentioned here in the new description and linked to here. This is a critical missing functionality. The customers are relying on the Jira audit log to reflect the main admin changes done by anybody, including apps. Unfortunately, the audit log simply doesn’t show anything done by the apps. This is a huge concern for our customer! And this makes it very hard for them to approve apps for usage. They simply cannot accept the risk of an app that has Jira admin permission, that can do everything in Jira, without ability to monitor it.

            Dave Thomas added a comment -

            @Jason - Actually, it's probably better to have a newer date on tickets describing the remaining issues. Here's why: when you have a ticket that's 20 years old, it's hard to know how many of the people who originally voted or commented on the issue still care about it. You don't know how many of those users are still using the product, how many found a different way to address the requirement, or if the issue's been resolved in some other fashion. In short, you have to spend a lot of time figuring out what's still relevant and what's not.

            With a new issue containing new votes, watchers, and comments, you don't have to waste time on all that. You know which people care about the issue and can be reasonably certain the comments are pertinent.

            Dave Thomas added a comment - @Jason - Actually, it's probably better to have a newer date on tickets describing the remaining issues. Here's why: when you have a ticket that's 20 years old, it's hard to know how many of the people who originally voted or commented on the issue still care about it. You don't know how many of those users are still using the product, how many found a different way to address the requirement, or if the issue's been resolved in some other fashion. In short, you have to spend a lot of time figuring out what's still relevant and what's not. With a new issue containing new votes, watchers, and comments, you don't have to waste time on all that. You know which people care about the issue and can be reasonably certain the comments are pertinent.

            Jason Armistead added a comment -

            This issue has been opened for nearly 20 years! And now, after all that time, it is not resolved and Atlassian decides to split it up into multiple issues.

            In fairness to the original user who reported this issue, all those new cases ought to have the same Created data of 16th February 2004 as well. That way the metrics on Atlassian's dashboard for tracking case lifecycles and closure times will reflect the true length of time that these have languished without getting the proper attention for what, in an increasingly cybersecurity and audit-aware business environment represent "base level" functionality that every modern product should have "baked in" from Day 1.

            And if the number of Votes and Watchers of those new issues is small, then Atlassian will inevitably fail to implement solutions because of a perceived "lack of user interest"

            Sheesh!

            Jason Armistead added a comment - This issue has been opened for nearly 20 years! And now, after all that time, it is not resolved and Atlassian decides to split it up into multiple issues. In fairness to the original user who reported this issue, all those new cases ought to have the same Created data of 16th February 2004 as well. That way the metrics on Atlassian's dashboard for tracking case lifecycles and closure times will reflect the true length of time that these have languished without getting the proper attention for what, in an increasingly cybersecurity and audit-aware business environment represent "base level" functionality that every modern product should have "baked in" from Day 1. And if the number of Votes and Watchers of those new issues is small, then Atlassian will inevitably fail to implement solutions because of a perceived "lack of user interest" Sheesh!

            Anusha Rutnam added a comment - - edited

            We are closing this ticket (JRACLOUD-3157) in favour of more specific feature requests.

            Hi everyone,

            Firstly, thank you for all the feedback you have provided on this ticket, JRACLOUD-3157 Jira Administration Audit trail / notifications. We understand the time and effort it takes to give such feedback and want you to know your contributions are appreciated.

            We are listening and want to improve audit logging. In order to get better fidelity on the types of audit logs we need most, we have split this suggestion into more specific tickets which are listed below. If you raised a support ticket about this problem and were linked to the issue, we have relinked your Support ticket to one of the most relevant features listed below.

            We recognise the demand for better audit logs that this issue represents, and breaking this ticket up into smaller, disparate issues will give us the best means of addressing the many individual concerns that have been raised here.

            If you have previously voted for JRACLOUD-3157 we encourage you to take the time to look through and voting for tickets listed in the Issue Links on the following tickets:

            This will help us understand demand and where to focus our development efforts.
             

            Request from the original description Current status
            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 (JRA-2555)            		 This is now tracked as a bug, here: JRACLOUD-80541 In site-level audit logs some actions are attributed to Author : JIRA despite having been enacted by a user
            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) this audit log now exists.
            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) this audit log now exists.
             
            Note if an existing custom field is added to a screen that will not shown in the audit log. The feature request for this can be voted for here JRACLOUD-67246 - Screen and screen scheme changes - Audit log feature request
            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) The feature request is now tracked here JRACLOUD-61853 Audit log should register Issue Type and Issue Type Scheme
            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! this audit log now exists.
            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 . The feature request is now tracked here JRACLOUD-75647 Log "General Configuration" changes in the audit log
            Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc. The feature request is now tracked here JRACLOUD-67246 - Screen and screen scheme changes - Audit log feature request
            For changes in the Time tracking provider, you can refer to JRACLOUD-8328
            Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc. I believe this request is now obsolete. Time format is now set at user-level. The format is controlled by the Language set here: <your site name>.atlassian.net/secure/ViewPersonalSettings.jspa
             
            More information on this feature can be found in the Description of this post.
             
            A feature request to change this functionality may be found here JRACLOUD-76814 – Allow further customization for date and date/time field (that's not limited to locale)
            There is no Audit log for the changes to Default "Priority" on the Global Priority Settings. An Admin can change the Default Priority from Medium to Low and the next created Issues take that priority by default. The feature request is now tracked here JRACLOUD-78430 Adding, reordering or removing priority does not log an entry in audit log
            Audit log doesn't capture "Issue Collectors" that are deleted from JIRA Projects The feature request is now tracked here JRACLOUD-81339 - Creation, edit and deletion of issue collectors - audit logs feature request
            Currently, the Audit Logs of Jira doesn't cover changes made to the filter. Creating multiple filters, changing the filter owner and modifying filters in the Jira Software. None of these activities is reflected in the audit log The feature request is now tracked here JRACLOUD-75028 Display more data on audit log about filter condition changes

             

             

            Anusha Rutnam added a comment - - edited We are closing this ticket ( JRACLOUD-3157 ) in favour of more specific feature requests. Hi everyone, Firstly, thank you for all the feedback you have provided on this ticket,  JRACLOUD-3157   Jira Administration Audit trail / notifications . We understand the time and effort it takes to give such feedback and want you to know your contributions are appreciated. We are listening and want to improve audit logging. In order to get better fidelity on the types of audit logs we need most, we have split this suggestion into more specific tickets which are listed below. If you raised a support ticket about this problem and were linked to the issue, we have relinked your Support ticket to one of the most relevant features listed below. We recognise the demand for better audit logs that this issue represents, and breaking this ticket up into smaller, disparate issues will give us the best means of addressing the many individual concerns that have been raised here. If you have previously voted for JRACLOUD-3157 we encourage you to take the time to look through and voting for tickets listed in the Issue Links on the following tickets: JRACLOUD-79986 - Tracking site-level audit log feature requests JRACLOUD-79984 - Tracking Organisation-level audit log feature requests This will help us understand demand and where to focus our development efforts.   Request from the original description Current status 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 ( JRA-2555 ) This is now tracked as a bug, here: JRACLOUD-80541 In site-level audit logs some actions are attributed to Author : JIRA despite having been enacted by a user 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) this audit log now exists. 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) this audit log now exists.   Note if an existing custom field is added to a screen that will not shown in the audit log. The feature request for this can be voted for here JRACLOUD-67246 - Screen and screen scheme changes - Audit log feature request 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) The feature request is now tracked here JRACLOUD-61853 Audit log should register Issue Type and Issue Type Scheme 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! this audit log now exists. 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 . The feature request is now tracked here JRACLOUD-75647 Log "General Configuration" changes in the audit log Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc. The feature request is now tracked here JRACLOUD-67246 - Screen and screen scheme changes - Audit log feature request For changes in the Time tracking provider, you can refer to JRACLOUD-8328 Currently, the Audit Logs of Jira doesn't cover "Time Tracking" Global Settings changes. Such as Site-Admin changes the format from Hours to Days. This is not recorded in the Audit logs and all of a sudden the Jira Issue's Time Tracking fields change the way they show Original Estimates, Time Tracking, etc. I believe this request is now obsolete. Time format is now set at user-level. The format is controlled by the Language set here: <your site name>.atlassian.net/secure/ViewPersonalSettings.jspa   More information on this feature can be found in the Description of this post.   A feature request to change this functionality may be found here JRACLOUD-76814 – Allow further customization for date and date/time field (that's not limited to locale) There is no Audit log for the changes to Default "Priority" on the Global Priority Settings. An Admin can change the Default Priority from Medium to Low and the next created Issues take that priority by default. The feature request is now tracked here JRACLOUD-78430 Adding, reordering or removing priority does not log an entry in audit log Audit log doesn't capture "Issue Collectors" that are deleted from JIRA Projects The feature request is now tracked here JRACLOUD-81339 - Creation, edit and deletion of issue collectors - audit logs feature request Currently, the Audit Logs of Jira doesn't cover changes made to the filter. Creating multiple filters, changing the filter owner and modifying filters in the Jira Software. None of these activities is reflected in the audit log The feature request is now tracked here JRACLOUD-75028 Display more data on audit log about filter condition changes    

            Yatish Madhav added a comment -

            +1 again

            Yatish Madhav added a comment - +1 again

            Gena Welk added a comment -

            This feature is greatly needed.  Thank you for considering.

            Gena Welk added a comment - This feature is greatly needed.  Thank you for considering.

            Andreea Florea added a comment -

            +1

            Andreea Florea added a comment - +1

            Felipe Rodrigues added a comment -

            This issue is only 19 years old - created on 16/Feb/2004 10:05 PM.

            Should Jira address it when its 2 decades later? For shame.. for shame...

            Felipe Rodrigues added a comment - This issue is only 19 years old - created on 16/Feb/2004 10:05 PM . Should Jira address it when its 2 decades later? For shame.. for shame...

            Phillip C added a comment -

            Ah yes, gathering interest on another basic feature - security this time.

            Phillip C added a comment - Ah yes, gathering interest on another basic feature - security this time.

            Héctor Sosa Fructuoso added a comment -

            This is, not only important but critical for any serious ISO-like certification. What it's the sense of tracking a change like creating a user, with when, what, how was created, but not by who?

            Got redirected to here from a support request.

            Héctor Sosa Fructuoso added a comment - This is, not only important but critical for any serious ISO-like certification. What it's the sense of tracking a change like creating a user, with when, what, how was created, but not by who? Got redirected to here from a support request.

              Unassigned Unassigned
              3b1ae0ec93c9 Nick Minutello
              Votes:
              920 Vote for this issue
              Watchers:
              612 Start watching this issue

                Created:
                Updated:
                Resolved: