-
Suggestion
-
Resolution: Duplicate
-
None
-
None
-
3
-
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
This is a feature entry to guage the interest in Atlassian providing an enterprise level auditer.
An enterprise level auditer would be distinguishable from currently available logging services for the following reasons:
- Logging information is accessible via the Administration UI.
- Logging info. can be persisted in a database table if needed.
- Logging priorities are configurable on a component by component basis - i.e. an admin. could choose to audit security at a detailed level but only receive general notices about content creation. This configuration would occur in the Administration UI.
Another possible point to consider is logging across a c cluster. If it ever appears the auditer might be leveraged to let admin.s administer federated logging.
Furthermore, it would be nice if the auditer could work across both Confluence and JIRA - both product customers probably have a need for this level of logging. I'm creating this issue under Confluence for the timebeing but it is a relevant consideration for JIRA also.
- duplicates
-
CONFSERVER-6960 Administration audit trail
- Closed
- is related to
-
CONFSERVER-6960 Administration audit trail
- Closed
-
CONFSERVER-8726 User Event Logging and Reporting
- Closed
- relates to
-
CONFCLOUD-3920 Enterprise level auditing
- Closed
-
JRASERVER-3157 JIRA Administration Audit trail / notifications
- Closed
- was cloned as
-
JRASERVER-7846 Enterprise level auditing
- Closed
[CONFSERVER-3920] Enterprise level auditing
Workflow | Original: JAC Suggestion Workflow 4 [ 3575395 ] | New: JAC Suggestion Workflow 3 [ 4336317 ] |
Workflow | Original: JAC Suggestion Workflow 2 [ 3167397 ] | New: JAC Suggestion Workflow 4 [ 3575395 ] |
Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
Workflow | Original: JAC Suggestion Workflow [ 3030858 ] | New: JAC Suggestion Workflow 2 [ 3167397 ] |
Workflow | Original: Confluence Workflow - Public Facing v4 [ 2532993 ] | New: JAC Suggestion Workflow [ 3030858 ] |
Workflow | Original: Confluence Workflow - Public Facing v3 [ 2291165 ] | New: Confluence Workflow - Public Facing v4 [ 2532993 ] |
Workflow | Original: Confluence Workflow - Public Facing v3 - TEMP [ 2185554 ] | New: Confluence Workflow - Public Facing v3 [ 2291165 ] |
Workflow | Original: Confluence Workflow - Public Facing v3 [ 1950419 ] | New: Confluence Workflow - Public Facing v3 - TEMP [ 2185554 ] |
Workflow | Original: Confluence Workflow - Public Facing v2 [ 1762925 ] | New: Confluence Workflow - Public Facing v3 [ 1950419 ] |
Description |
Original:
This is a feature entry to guage the interest in Atlassian providing an enterprise level auditer.
An enterprise level auditer would be distinguishable from currently available logging services for the following reasons: * Logging information is accessible via the Administration UI. * Logging info. can be persisted in a database table if needed. * Logging priorities are configurable on a component by component basis - i.e. an admin. could choose to audit security at a detailed level but only receive general notices about content creation. This configuration would occur in the Administration UI. Another possible point to consider is logging across a c cluster. If it ever appears the auditer might be leveraged to let admin.s administer federated logging. Furthermore, it would be nice if the auditer could work across both Confluence and JIRA - both product customers probably have a need for this level of logging. I'm creating this issue under Confluence for the timebeing but it is a relevant consideration for JIRA also. |
New:
{panel:bgColor=#e7f4fa} *NOTE:* This suggestion is for *Confluence Server*. Using *Confluence Cloud*? [See the corresponding suggestion|http://jira.atlassian.com/browse/CONFCLOUD-3920]. {panel} This is a feature entry to guage the interest in Atlassian providing an enterprise level auditer. An enterprise level auditer would be distinguishable from currently available logging services for the following reasons: * Logging information is accessible via the Administration UI. * Logging info. can be persisted in a database table if needed. * Logging priorities are configurable on a component by component basis - i.e. an admin. could choose to audit security at a detailed level but only receive general notices about content creation. This configuration would occur in the Administration UI. Another possible point to consider is logging across a c cluster. If it ever appears the auditer might be leveraged to let admin.s administer federated logging. Furthermore, it would be nice if the auditer could work across both Confluence and JIRA - both product customers probably have a need for this level of logging. I'm creating this issue under Confluence for the timebeing but it is a relevant consideration for JIRA also. |
Link |
New:
This issue relates to |