audit_log.rst 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135
  1. .. _audit_log:
  2. Audit log
  3. =========
  4. Wagtail provides a mechanism to log actions performed on its objects. Common activities such as page creation, update, deletion,
  5. locking and unlocking, revision scheduling and privacy changes are automatically logged at the model level.
  6. The Wagtail admin uses the action log entries to provide a site-wide and page specific history of changes. It uses a
  7. registry of 'actions' that provide additional context for the logged action.
  8. The audit log-driven Page history replaces the revisions list page, but provide a filter for revision-specific entries.
  9. .. note:: The audit log does not replace revisions.
  10. The ``wagtail.core.log_actions.log`` function can be used to add logging to your own code.
  11. .. function:: log(instance, action, user=None, uuid=None, title=None, data=None)
  12. Adds an entry to the audit log.
  13. :param instance: The model instance that the action is performed on
  14. :param action: The code name for the action being performed. This can be one of the names listed below, or a custom action defined through the :ref:`register_log_actions` hook.
  15. :param user: Optional - the user initiating the action. For actions logged within an admin view, this defaults to the logged-in user.
  16. :param uuid: Optional - log entries given the same UUID indicates that they occurred as part of the same user action (e.g. a page being immediately published on creation).
  17. :param title: The string representation of the instance being logged. By default, Wagtail will attempt to use the instance's ``str`` representation, or ``get_admin_display_title`` for page objects.
  18. :param data: Optional - a dictionary of additional JSON-serialisable data to store against the log entry
  19. .. note:: When adding logging, you need to log the action or actions that happen to the object. For example, if the
  20. user creates and publishes a page, there should be a "create" entry and a "publish" entry. Or, if the user copies
  21. a published page and chooses to keep it published, there should be a "copy" and a "publish" entry for new page.
  22. .. code-block:: python
  23. # mypackage/views.py
  24. from wagtail.core.log_actions import log
  25. def copy_for_translation(page):
  26. # ...
  27. page.copy(log_action='mypackage.copy_for_translation')
  28. def my_method(request, page):
  29. # ..
  30. # Manually log an action
  31. data = {
  32. 'make': {'it': 'so'}
  33. }
  34. log(
  35. instance=page, action='mypackage.custom_action', data=data
  36. )
  37. .. versionchanged:: 2.15
  38. The ``log`` function was added. Previously, logging was only implemented for pages, and invoked through the ``PageLogEntry.objects.log_action`` method.
  39. Log actions provided by Wagtail
  40. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  41. =================================== =====
  42. Action Notes
  43. =================================== =====
  44. ``wagtail.create`` The object was created
  45. ``wagtail.edit`` The object was edited (for pages, saved as draft)
  46. ``wagtail.delete`` The object was deleted. Will only surface in the Site History for administrators
  47. ``wagtail.publish`` The page was published
  48. ``wagtail.publish.schedule`` Draft is scheduled for publishing
  49. ``wagtail.publish.scheduled`` Draft published via ``publish_scheduled_pages`` management command
  50. ``wagtail.schedule.cancel`` Draft scheduled for publishing cancelled via "Cancel scheduled publish"
  51. ``wagtail.unpublish`` The page was unpublished
  52. ``wagtail.unpublish.scheduled`` Page unpublished via ``publish_scheduled_pages`` management command
  53. ``wagtail.lock`` Page was locked
  54. ``wagtail.unlock`` Page was unlocked
  55. ``wagtail.moderation.approve`` The revision was approved for moderation
  56. ``wagtail.moderation.reject`` The revision was rejected
  57. ``wagtail.rename`` A page was renamed
  58. ``wagtail.revert`` The page was reverted to a previous draft
  59. ``wagtail.copy`` The page was copied to a new location
  60. ``wagtail.copy_for_translation`` The page was copied into a new locale for translation
  61. ``wagtail.move`` The page was moved to a new location
  62. ``wagtail.reorder`` The order of the page under it's parent was changed
  63. ``wagtail.view_restriction.create`` The page was restricted
  64. ``wagtail.view_restriction.edit`` The page restrictions were updated
  65. ``wagtail.view_restriction.delete`` The page restrictions were removed
  66. ``wagtail.workflow.start`` The page was submitted for moderation in a Workflow
  67. ``wagtail.workflow.approve`` The draft was approved at a Workflow Task
  68. ``wagtail.workflow.reject`` The draft was rejected, and changes requested at a Workflow Task
  69. ``wagtail.workflow.resume`` The draft was resubmitted to the workflow
  70. ``wagtail.workflow.cancel`` The workflow was cancelled
  71. =================================== =====
  72. Log context
  73. ~~~~~~~~~~~
  74. The ``wagtail.core.log_actions`` module provides a context manager to simplify code that logs a large number of actions,
  75. such as import scripts:
  76. .. code-block:: python
  77. from wagtail.core.log_actions import LogContext
  78. with LogContext(user=User.objects.get(username='admin')):
  79. # ...
  80. log(page, 'wagtail.edit')
  81. # ...
  82. log(page, 'wagtail.publish')
  83. All ``log`` calls within the block will then be attributed to the specified user, and assigned a common UUID. A log context
  84. is created automatically for views within the Wagtail admin.
  85. Log models
  86. ~~~~~~~~~~
  87. Logs are stored in the database via the models ``wagtail.core.models.PageLogEntry`` (for actions on Page instances) and
  88. ``wagtail.core.models.ModelLogEntry`` (for actions on all other models). Page logs are stored in their own model to
  89. ensure that reports can be filtered according to the current user's permissions, which could not be done efficiently
  90. with a generic foreign key.
  91. If your own models have complex reporting requirements that would make ``ModelLogEntry`` unsuitable, you can configure
  92. them to be logged to their own log model; this is done by subclassing the abstract ``wagtail.core.models.BaseLogEntry``
  93. model, and registering that model with the log registry's ``register_model`` method:
  94. .. code-block:: python
  95. from myapp.models import Sprocket, SprocketLogEntry
  96. # here SprocketLogEntry is a subclass of BaseLogEntry
  97. @hooks.register('register_log_actions')
  98. def sprocket_log_model(actions):
  99. actions.register_model(Sprocket, SprocketLogEntry)