Table of Contents

Auditing

The Auditing component shows the changes history of an item — every add, update, delete, or relationship change made by any operator. It appears as a drawer that the user opens from an edit page.

Related docs.
EditHistory Microservice — the service that stores and serves the audit data.
MibApi Auditing — Data-API-side configuration that hooks the change-listener into save operations.
Page Configuration — ALLOW_AUDIT_VIEW — the per-page toggle.

Where the data comes from

The audit drawer is the React-shell view of the EditHistory Microservice. Every time an operator persists a change through the Data API:

  1. The Data API's MibObjects pipeline fires the MibEditHistoryListener (registered through MibObjectNotificationConfig).
  2. The listener POSTs the change description (modified fields, added / removed relations, operation type) to the EditHistory MS, which stores it in MongoDB.
  3. When the operator opens the audit drawer on the BFF, the BFF calls POST /edithistory/v1/read/<mediaType>/<id>?page=N&limit=M and forwards the result to the React shell.

If the EditHistory MS isn't configured (or UseEditHistoryMicroService is false on the BFF), the drawer opens empty. See the EditHistory docs for setup.

Enabling the audit drawer on a page

Three ingredients are required for the drawer to be visible AND populated:

  1. BFF flag — UseEditHistoryMicroService = true on the BFF's MibCmsFrontEndServerBaseConfig, plus the EditHistory MS reachable at MibEditHistoryMicroServiceClientConfig.ApiUrl.
  2. Per-page flag — ALLOW_AUDIT_VIEW = true in MIB3UX_PAGE_CONFIGURATIONS for each page that should expose the drawer.
  3. Data API listener registration — see Data API configuration below. Without this, the drawer renders but is empty because no save events are being captured.

Without (1) or (2), the audit button is hidden. Without (3), the button appears but the drawer is empty.

Using the audit drawer

On any edit page where auditing is enabled, click the audit button in the top-right toolbar ( ). A right-side drawer titled Edition History opens with all changes to the current item, sorted newest-first:

Edition History drawer showing one audit entry on a movies edit page

  1. The drawer header has a media-type selector — pick a related media type to switch the audit view to a related record. The list of selectable media types is built from the page's components (Form, RelatedList, RelatedForm, AutoComplete — every component that declares a main media type contributes).
  2. Click the search icon ( ) to pick a related record once you've changed media type.
  3. Each row in the list represents one save operation, showing Register ID, Username (with avatar), Media Type, and Date.
  4. Click the chevron at the start of a row to expand it and see the field-level changes (added/changed/removed fields and relations).
  5. Click the reset icon ( ) to return to the main item's audit view.
  6. Click the back arrow at the top of the drawer to close it.

What is logged

Each entry corresponds to one save operation and describes:

  • Operation type — Added, Changed, Removed, AddedRelation, RemovedRelation.
  • Modified fields — for Added / Changed / Removed. Each field carries name, originalValue, newValue. Fields marked hidden in the audit configuration (e.g. password fields) are excluded.
  • Added / removed relations — for AddedRelation / RemovedRelation. Carries the related media type and id.
  • Audit information — instanceId, requestId, pageKey, source, tags. Useful for cross-referencing with BFF logs (the requestId matches the BFF's x-request-id correlation header).
  • User — id, name, email, optional avatar URL.
  • Timestamp — UTC.

See the EditHistory Microservice API for the full data shape.

Read-permission filtering

When the BFF requests the audit data, it passes the user's read permissions to the EditHistory MS. Entries that reference related records the user cannot read are filtered out before reaching the client. The result: a low-permission user sees only the partial audit trail they're allowed to see, not "redacted" entries.

Troubleshooting

Symptom Likely cause
Audit button is missing ALLOW_AUDIT_VIEW is not true on the page config, or UseEditHistoryMicroService is false on the BFF.
Drawer opens but is empty EditHistory MS unreachable, or no changes have been recorded yet (audit logs from before the listener was wired up don't exist).
Mediatype selector has no options The page has no components with a main mediatype set — check the Form/RelatedList/RelatedForm/AutoComplete component configurations.
Entries are missing or partial Read-permission filtering may be removing entries the current user can't see. Test as a higher-permission user to confirm.
requestId mismatch with BFF log Older entries may pre-date the request-id correlation header. New entries should always match.

See EditHistory — troubleshooting for service-side diagnostics (the records may not be in MongoDB at all).

Data API configuration

For auditing to actually capture changes, the Data API needs the listener registered:

MIBOBJECTNOTIFICATIONCONFIG_DEFAULT_NOTIFICATIONASSEMBLYNAME=MediaiBox.Cms.MicroServices.EditHistory.Listener
MIBOBJECTNOTIFICATIONCONFIG_DEFAULT_NOTIFICATIONCLASSFULLNAME=MediaiBox.Cms.MicroServices.EditHistory.Listener.MibEditHistoryListener

Plus the EditHistory client config pointing at the MS. See MibApi Auditing for the full Data-API setup.

See also

Edit this page