Event journal¶
The Event journal module records who did what, when, on which entity and in which organization. Every module of the platform drops its notable facts there — a validated inventory, an executed operation, a data export — and the journal gathers them into a single list, browsable and exportable.
Who is it for?¶
Any organization that has to account for itself: finding the author of a stock correction, justifying a goods issue during an audit, or simply understanding the chain of actions that led to the current state of a record.
A business journal, not a technical one
The module only collects business facts. Technical traces — application errors, response times, server restarts — live elsewhere and never reach this journal. An event reads like a sentence: Awa Koné validated inventory INV-2026-0042.
What the module does¶
- Gather the events of every module into a single list, specific to your organization
- Filter that list by source, by type, by level, by period or by free text
- Detail an event: its actor, its entity, and the business data that comes with it
- Export a search result as CSV, the export itself being journaled
- Collect the messages the platform could not read, in the dead letters screen
The screens¶
Event journal¶
The main screen lists events from the most recent to the oldest. Every row carries the date, the source, the type, the actor, the entity concerned and the level. The filters — source, type, level, period, free search — combine with each other, and the eye icon opens the detail of a row.
The detail repeats the header of the event and shows its business data as it stands, in JSON: the module does not interpret it, it restitutes it.
The Export CSV button saves the current search result, filters included.
Dead letters¶
A message that no rule can read — malformed envelope, invalid type, size exceeded — is not lost: it is set aside and presented in the Dead letters screen. That screen serves diagnosis; under normal circumstances, it stays empty.
The levels¶
| Level | When it is used |
|---|---|
INFO |
The common case: an ordinary business fact, successful |
WARN |
A fact that deserves attention without being a fault |
SECURITY |
A sign-in, a denied permission, a data export |
ERROR |
A notable business failure |
The permissions¶
The rights of the module are prefixed with LOGS. and follow the LOGS.RESOURCE.ACTION shape. None is restricted by establishment or by point of sale: they hold for the whole organization.
| Code | Label | What it allows |
|---|---|---|
LOGS.EVENT.READ |
Browse the journal | Open the Event journal screen, filter the list and read the detail of an event |
LOGS.EVENT.EXPORT |
Export the journal | Use the Export CSV button |
LOGS.DLQ.READ |
Browse the dead letters | Open the Dead letters screen |
Two profiles are recommended:
| Code | LOGS.EVENT.READ |
LOGS.EVENT.EXPORT |
LOGS.DLQ.READ |
|---|---|---|---|
ADMINISTRATOR |
Yes | Yes | Yes |
AUDITOR |
Yes | Yes | — |
Exporting is a journaled act
An export itself emits the logs.events.exported event, of level SECURITY, with the filters used. Taking data out of the platform therefore leaves a trace inside the platform.
Linking to the journal from another module¶
A module that displays an entity may offer a link to its history. The journal screen accepts two address parameters, subjectType and subjectId, and opens already filtered on that entity:
#/events?subjectType=inventory&subjectId=6f1c8e2a-9b34-4d51-8a7e-2c3f5b1d0e77
The type and the identifier are the ones the emitting module put in the subject of the event. Such a link spares the user from rebuilding the filter by hand.
How events arrive¶
Modules do not write into the journal: they publish an envelope on the logs topic of Apache Pulsar, and the module consumes it on its own account. The emitter waits for nothing and knows nothing of the storage.
Events are kept for 24 months by default. That duration, retention-months, is set for the whole platform and not organization by organization.
Contents¶
Changelog¶
- 1.0 (August 23, 2026): document created.