Use Admin > Users > User Activity to audit web-interface, API, authentication, configuration, campaign, provider-number, and maintenance operations recorded by MiRTA PBX. From the Users list, select a user before choosing User Activity to open a prefiltered log, or open it without a selected row to review all activity available to your account.
The page requires the Has menu Admin/Users privilege. Administrators with Can edit all tenants can review all tenant activity. Administrators limited to their own tenants see only activity allowed by their tenant and user scope.
Admin User Activity page with fictional documentation events.
This screenshot was captured from the current MiRTA PBX server. The displayed activity rows are fictional documentation values inserted only in the browser; no PBX records or activity-log rows were changed.
Working with the log
Control
Purpose
Search
Filters the log. When advanced filters are enabled, multiple rules and groups can be combined.
View
Opens the selected row and shows fields that are hidden in the default grid.
Undo
Attempts to restore the saved old values for a selected UPDATE or DELETE row. See Undo limitations before using it.
Columns
Shows, hides, or reorders columns. The choice is retained in the current browser.
CSV Export
Exports the activity data and all supported columns for offline review.
Columns
Column
Description
ID
Unique activity-log row ID.
Date
Date and time at which the event was logged.
Tenant
Tenant associated with the operation. System-wide operations can have no tenant name.
User
Web username or process label responsible for the event. Examples include OPENAPI, AUTO, or housekeeping.
Action
Short operation code. The current standard codes are described below.
Host
Client IP address. When location data is available, the interface also displays the country flag and name.
User Agent
Browser or API client user-agent string.
Country code / Country
Location resolved from the client IP address when the event was written.
Table
Database table or logical object associated with the operation. A suffix such as -de_destinations identifies related routing destinations.
Table ID
Database or logical record identifier used by the operation.
Table value
Human-readable value used to identify the affected object, such as an extension number or object name.
Old values
Field values captured before the operation.
New values
Field values captured after the operation.
Changed values
Calculated summary for standard insert, update, delete, and failed-upgrade events.
Requested URI
Host and web path that generated the log row.
Important: activity details can contain configuration values, addresses, object names, and request information. Restrict access to trusted administrators and protect exported CSV files accordingly. Passwords and other secrets are masked by supported logging paths, but historical or custom log writers might not apply the same masking.
Record and page-change actions
Action code
Meaning
INSERT
A new database or logical record was created. New values contains the captured state.
UPDATE
An existing record was modified. Compare Old values, New values, and Changed values.
DELETE
A record was removed. Old values contains the captured state before deletion.
UNDO UPDATE
An administrator used User Activity to restore the old values of an UPDATE row.
UNDO DELETE
An administrator used User Activity to recreate a record from a DELETE row.
PAGE CHANGE
Automatic fallback audit entry written when a page changed the database without writing a more specific activity row. The old side contains a sanitized request; the new side summarizes detected SQL mutations.
Authentication and security actions
Action code
Meaning
LOGIN
Successful web-interface login.
LOGIN FAILED
The supplied web credentials were not accepted.
reCAPTCHA FAILED
The login request failed the configured reCAPTCHA check.
LOGIN FROM IP NOT ALLOWED
The global web GeoIP policy rejected the source IP country.
TOO MANY FAILED LOGIN FROM IP
Web fail2ban rejected the source IP after too many recent failures.
LOGIN BLOCKED BY IP
The user account IP filter did not allow the source IP address.
LOGIN DISABLED BY INACTIVITY
A login was refused because inactivity housekeeping had disabled the account.
LOGOUT
The user logged out, or the session was terminated for a security reason such as an unexpected IP change. Review the values for the reason when present.
DISABLED BY INACTIVITY
Housekeeping disabled a web user or extension after the configured period without a successful login.
GOOGLE 2FA GENERATED
A Google Authenticator secret was generated or enrolled for a user.
MULTIMANAGER LOGIN
Successful login to the MiRTA PBX MultiManager socket service.
MULTIMANAGER LOGIN FAILED
Failed login to the MultiManager socket service.
MULTIMANAGER LOGOUT
Logout from the MultiManager socket service.
Campaign actions
Action code
Meaning
START
The selected campaign was requested to start.
STOP
The selected campaign was stopped and returned to the ready state.
PAUSE
The selected campaign was paused.
RESUME
The selected campaign was resumed.
RESETCALLS
Attempt, disposition, duration, and related call-result fields were reset for the selected campaign numbers.
SIP and runtime-state actions
Action code
Meaning
RESET
An extension, virtual extension, flow, BLF, or related runtime state was reset to the value shown in New values.
PRUNING
A SIP or PJSIP endpoint was pruned from runtime state while maintaining or refreshing an extension.
UNREGISTERING
A SIP or PJSIP endpoint was explicitly unregistered while changing or deleting an extension.
System, report, and access actions
Action code
Meaning
READ
A protected object was opened or retrieved by a logging-enabled path, currently including provider details and recording access. It does not mean that every ordinary page view is logged as READ.
EXECUTE
A configured report was executed. The logged values include the requested date range and generated report-data ID when available.
TESTSENDEMAIL
The test-send action was used for an email template.
DATABASE UPGRADE
A database upgrade step completed and advanced the stored database version.
FAILED DATABASE UPGRADE
A database upgrade step failed. Review the old/new version and saved error message, then also check the process and PHP logs.
DID-provider and emergency-data actions
Action code
Meaning
NUMBER ALLOCATE
A number was allocated through a supported DID provider.
NUMBER ACTIVATE
An allocated DID-provider number was activated.
NUMBER ASSIGNED
A provider number or number from a block was assigned to a MiRTA PBX tenant/DID record.
NUMBER SET
Routing targets for a DID-provider number were changed.
NUMBER DEACTIVATE
A DID-provider number was deactivated.
BLOCK NUMBER ACTIVATE
A block of provider numbers was activated.
BLOCK DEACTIVATE
A block of provider numbers was deactivated.
999 SET
UK emergency-service address data for a provider number was changed.
999 CREATE
A UK emergency-service address record was created for a provider number.
Additional action codes
The Action field is a text value, not a fixed database enumeration. The tables above list every standard literal code used by the current MiRTA PBX source, while dynamic CRUD logging resolves to INSERT, UPDATE, or DELETE. Older releases, plugins, integrations, or local customizations can write other codes. Interpret an unfamiliar code together with User, Table, Table value, the old/new values, and Requested URI.
Undo limitations
Undo is available only for rows whose action is exactly UPDATE or DELETE.
The activity row must contain enough saved old values to identify the table, primary key, and restorable columns.
For an update, the target record must still exist. For a delete, a record with the same key must not already exist.
Routing-destination logs receive special handling, but Undo otherwise restores one logged table at a time. Related rows, generated configuration, caches, and runtime state are not automatically guaranteed to be restored.
A successful operation creates an UNDO UPDATE or UNDO DELETE audit row.
Recommendation: inspect the complete row first, take an appropriate backup, and use the normal configuration page when the change affects multiple related objects or runtime configuration. After Undo, verify the object and apply any normal reload or regeneration step required by that feature.
Revision #2
Created 2026-08-25 20:27:54 UTC by Admin
Updated 2026-08-25 20:27:55 UTC by Admin
