Auditing

Changes on any data are trackable. The XMM provides a configurable system that lets administrators define which data is tracked and how changes are logged.

Tracked changes are saved in the database with this information:

  • document: Changed document (a user, an article, …)

  • created_dt: Time and date of change

  • created_user: Author of change

  • changed_fields: New values of the fields (key => value)

Configuration

Setting up auditing of system and masterdata records is done by configuring the AUDITING variable in a project’s settings module.

Tracking configuration should specify which models should be tracked, e.g. only changes to the masterdata model “Products” will be tracked.

Every tracked model must specify which fields should be tracked.

Example AUDITING configuration:

AUDITING = {
    # Basic configuration, only tracks permission changes made on users.
    'User': {
        'track_changes': True,  # must be True, otherwise nothing is tracked
        'fields': ['roles', 'permissions', 'is_superuser'],
        'max_retention_count': 100,  # Keep at most 100 changes...
        'min_retention_count': 4,  # but always keep at least the 10 most recent changes
        'retention_age': {'weeks': 4},  # Remove entries older than 4 weeks (**kwargs for timedelta)
    },
    # Fully configured audit config with default values for a
    # custom model called 'my_model'
    'my_model': {
        'track_changes': True,
        'fields': ['fields.my_custom_field'],  # how to log custom attributes
    },
}

Possible options can also include tracking only changes made by users of a certain group (e.g. “interns”) or individual users.

Note

Planned feature, not yet implemented.

To prevent stuffing the database full of tracking data, tracked items should be limited to a specified count of timespan, e.g. keep changes saved for at most 6 months and at most 100 changes, but always keep at least the last 10 changes.

Note

Planned feature, not yet implemented.

Technical implementation

The audit tracking model must provide a class method that:

  • gets called in the post_save hook of a model
    • optionally only if the model itself is tracked at all

  • check the last tracked change if any

  • check the field values of the last change
    • create a new entry if the values of tracked fields actually changed