Journal
The "Journal" module in Platform OneEntry allows administrators to track both the actions of other admins in the system and the activity of the public Content API. The module consists of four tabs:
| Tab | What it shows |
|---|---|
| Admin Actions Log | All actions taken by administrators in the system: creation, modification, deletion of entities. |
| Admin Traffic | Admin login sessions: when they logged in, when they logged out, from which device. |
| Content API Statistics | Call counters for all public endpoints of the site over different periods. |
| Content API Errors | All 4xx/5xx responses from the public API with request details and stack trace. |
In the module interface, the tabs are labeled as follows: Admin Journal, Access Log to Admin Application, Content API Statistics, Content API Errors.
Each tab is available under a separate permission — see Permissions for the Journal.
Admin Actions Log
The main tab that shows all actions taken by administrators in the system. It was previously called simply "Admin Actions Log" — it has now been renamed to "Admin Actions Log" to distinguish it from the new tabs.
Interface Elements
The tab consists of two blocks:
- Filters
- List of actions
Filters
The following fields are available for filtering actions:
- From — a text input field for the date from which actions need to be filtered.
- To — a text input field for the date until which actions need to be filtered.
Dates can be entered as a string in your region's date format, or you can select the desired date using the calendar that appears when you click on the date input field.
- Administrator ID — a numeric input field for the unique identifier of the administrator.
- User actions — a dropdown list of user actions:
- Creation
- Modification
- Deletion
- Status — a dropdown list of action statuses:
- Successful
- Error
- Module name — a dropdown list of module names:
- Administrators
- Sets of attributes
- Backup
- Managing blocks
- Event management
- General settings
- Uploading files
- File editor
- Managing forms
- Localization
- Markers
- Menu
- Modules
- Content management
- Products
- Order management
- Basic settings
- Payment management
- Product status management
- USER
- Authentication providers and users management
- Template management
- Preview template management
- Record ID — a numeric input field for the unique identifier of the record.
Below the filter block, there are two buttons:
- Delete data — deletes admin action log entries for the period specified by the From / To fields (see Manual Log Cleanup).
- Reset — resets the applied filters.
List of Actions
The list of actions is presented in a table with six columns:
- User actions
- Status
- User login
- Module name
- Record ID
- Date and time
For each column, you can sort the data by clicking on the column header. The first click sorts in descending order, the second in ascending order, and the third resets the sorting.
Block Visibility Audit
Each block visibility toggle (the "show/hide" toggle in the admin block) is automatically recorded in the Admin Actions Log. It shows which admin changed the state of a specific block and when.
The block visibility toggle was not recorded in the log — it was impossible to determine who and when hid/showed the block. Now this is available, and the operation is displayed in the general list with the type "Managing blocks."
Admin Traffic (Admin Access Log)
The "Admin Traffic" tab shows each login and logout of an administrator in the system as a separate entry. You can now immediately see who logged into the admin panel and when — without referring to Grafana/Loki. This is useful for auditing (especially for large teams with multiple admins).
Table Fields
The table consists of six columns:
| Column | Meaning |
|---|---|
| Login | the administrator's login |
| IP | the IP address from which the admin logged in |
| Login Time | the date and time of login |
| Logout Time | the date and time of logout (for still open sessions — empty) |
| Duration | the duration of the session (for active sessions — from login to the current moment) |
| Reason | the reason for closing the session: logout (the admin clicked "Logout") or admin_revoked (another admin forcibly ended the session, for example, through logoutAll) |
As in the Admin Actions Log, any column can be sorted by clicking on its header.
Token expiration (expired) and reauthorization (refresh) are not logged as a separate entry — such a session is simply marked as closed lazily when it is no longer actively used.
Filters
- From / to — period (date input fields with a calendar).
- Administrator ID — a numeric field for filtering by a specific administrator.
- Session Status — a dropdown list of session statuses: All / Active / Closed.
"Delete Data" Button
Deletes session records for the period specified by the From / To fields. When clicked, a confirmation dialog opens:
Confirm action — Delete all closed sessions for the specified period? This action is irreversible. Active sessions will remain.
Only closed sessions are deleted. Active sessions (with open authorization) are not affected — this is a safeguard against accidentally "killing" working colleagues.
Content API Statistics
The "Content API Statistics" tab shows call counters for all public endpoints of the site (storefront API) over different periods — 1 hour, 24 hours, 7 days.
What it Shows
- List of all public endpoints (
GET /api/content/...) — auto-collected from the code, nothing needs to be maintained manually. - Counter next to each endpoint — how many times it was called during the selected period.
- The numbers are taken from the centralized Prometheus metrics of nginx-ingress, which is responsible for our traffic. No separate counters are created in the project's database.
Interface Elements
- Period — a dropdown list of periods: Last Hour / Last 24 Hours / Last 7 Days (default is Last 24 Hours).
- Refresh — a button for forcing data refresh.
Data is presented in a table with four columns:
| Column | Meaning |
|---|---|
| Path | the endpoint path (/api/content/...) |
| Method | HTTP method (GET, POST, …) |
| Description | a brief description of the endpoint |
| Requests | the number of calls during the selected period |
At the top of the page, an informational banner is displayed:
Auto-cleanup not applicable — Data is read in real-time from Prometheus, retention is configured at the monitoring infrastructure level. This tab does not store data in the CMS database.
If Prometheus is unavailable, a warning appears above the table stating "Metric temporarily unavailable. All endpoints are displayed with a zero count." — the list of endpoints is still displayed, but with a count of 0.
Data is stored in Prometheus with infrastructure-level retention (usually 30 days). For longer-term analytics, you need to store it yourself. The informational banner at the top of the page warns about this.
Why It’s Needed
Marketing and product teams can see which features of the storefront API are actually used and which are dead. It is also convenient to monitor "is everything alive" — a sharp drop in calls to a single endpoint usually indicates a problem on the frontend side.
The response is cached for 60 seconds in Redis — to avoid hitting Prometheus with every "Refresh" click.
Content API Errors
The "Content API Errors" tab shows all 4xx/5xx responses that the public API returned over a period. Developers integrating their client applications with our API no longer need access to server logs — they can see all errors for their requests directly in the admin panel.
What It Shows
Each entry is a separate HTTP error. The table consists of five columns:
| Column | Meaning |
|---|---|
| Time | timestamp of the error |
| Status | HTTP status (4xx / 5xx) |
| Method | request method (GET, POST, …) |
| Path | path (/api/content/...) |
| Message | error text |
If there were no errors during the selected period, a message "No errors recorded for the selected period" is displayed instead of the table.
The "Details" field opens a detailed screen with:
- Request body (without secrets — passwords, tokens, authorization headers are masked)
- Query — query string parameters
- Headers
- Stack trace — expanded (up to 8 KB)
Filters
- From / to — period (date input fields with a calendar).
- HTTP Status — a dropdown list of statuses. You can select a group (4xx - Client-side, 5xx - Server-side) or a specific code: 400, 401, 403, 404, 422, 500, 502, 503.
- Path — a text field for filtering by path (for example,
/api/content/blocks/*).
"Delete Data" Button
Deletes error records for the period specified by the From / To fields. If no period is specified — deletes all errors.
Security — Sanitizer
The sanitizer automatically removes sensitive data. Fields password, token, authorization, api_key, x-app-token, cookie, set-cookie (case insensitive) are replaced with ***. Large bodies are truncated to 2 KB.
Architecture
Errors are logged through a lightweight queue Bull, so logging does not slow down request processing. If the queue is full (more than 1000 pending jobs) — new errors are quietly discarded to avoid "crashing" Redis.
Manual Log Cleanup
Log entries are cleared manually — on each tab that stores data in the database, there is a "Delete data" button:
| Tab | What it Deletes |
|---|---|
| Admin Actions Log | admin action records for the selected period |
| Admin Traffic | only closed sessions for the selected period |
| Content API Errors | error records for the selected period |
The deletion period is specified by the From / To fields in the tab filters. If no period is specified — all records of the corresponding type are deleted. A confirmation dialog "Confirm action" is always shown before deletion, and the operation is irreversible.
The "Delete data" button on the "Admin Traffic" tab does not delete active admin sessions — even if a period is specified that overlaps the current moment, the open session of a working colleague will not be deleted. Only closed sessions are deleted.
The statistics data is read in real-time from Prometheus and is not stored in the CMS database, so there is no "Delete data" button on this tab — this is indicated by the banner "Auto-cleanup not applicable."
Permissions for the Journal
Each journal tab is available under a separate permission in the permissions tree:
| Tab | Permission |
|---|---|
| Admin Actions Log | journal.viewAdminActions (existing permission, unchanged) |
| Admin Traffic | journal.viewAdminAccess (new permission) |
| Content API Statistics | journal.viewContentApiStats (new permission) |
| Content API Errors | journal.viewContentApiErrors (new permission) |
When updating the system, both new permissions (journal.viewContentApiStats, journal.viewContentApiErrors) are automatically granted to all existing admins with the admins.get permission — through seed migration. Nothing was broken for current roles.