Find out who changed their records, what and when: a Kimai 2 plugin to record and visualize the changes on
You can test it in the “Plugins” demo.
Adds new actions to each of the following items in the admin section:
Introduces a new screen for each of the above items, with all recorded changes and each log entry containing the following information:
The following fields are recorded for changes:
The following features will be added in the future:
Create the required tables for your database engine.
Either MySQL / MariaDB:
CREATE TABLE kimai2_ext_log_entries (id INT AUTO_INCREMENT NOT NULL, action VARCHAR(8) NOT NULL, logged_at DATETIME NOT NULL COMMENT '(DC2Type:datetime)', object_id VARCHAR(64) DEFAULT NULL, object_class VARCHAR(255) NOT NULL, version INT NOT NULL, data LONGTEXT DEFAULT NULL COMMENT '(DC2Type:array)', username VARCHAR(255) DEFAULT NULL, INDEX log_class_lookup_idx (object_class), INDEX log_date_lookup_idx (logged_at), INDEX log_user_lookup_idx (username), INDEX log_version_lookup_idx (object_id, object_class, version), PRIMARY KEY(id));
CREATE TABLE kimai2_ext_log_entries (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, "action" VARCHAR(8) NOT NULL, logged_at DATETIME NOT NULL, object_id VARCHAR(64) DEFAULT NULL, object_class VARCHAR(255) NOT NULL, version INTEGER NOT NULL, data CLOB DEFAULT NULL, username VARCHAR(255) DEFAULT NULL); CREATE INDEX log_class_lookup_idx ON kimai2_ext_log_entries (object_class); CREATE INDEX log_date_lookup_idx ON kimai2_ext_log_entries (logged_at); CREATE INDEX log_user_lookup_idx ON kimai2_ext_log_entries (username); CREATE INDEX log_version_lookup_idx ON kimai2_ext_log_entries (object_id, object_class, version);
Extract the ZIP file and upload the included directory and all files to your Kimai installation to the new directory:
The file structure needs to like like this afterwards:
var/plugins/ ├── AuditTrailBundle │ ├── AuditTrailBundle.php | └ ... more files and directories follow here ...
After uploading the files, Kimai needs to know about the new plugin. It will be found, when the cache is re-build:
cd kimai2/ bin/console cache:clear --env=prod bin/console cache:warmup --env=prod
or when using FTP: delete the folder
When logged in as
SUPER_ADMIN, you should now see the audit log screens (find the links in the “actions” dropdown menus).
If this was successful, you can now think about giving permissions to other users as well.
This bundle ships new administration screens, which are available for the following users:
ROLE_SUPER_ADMIN- every super administrator has access to all audit logs
audit_customer- everyone with this permission can see all changes for the customer objects
audit_project- everyone with this permission can see all changes for the project objects
audit_activity- everyone with this permission can see all changes for the activity objects
audit_own_timesheet- everyone with this permission can see all changes for his own timesheets (only via team timesheets)
audit_other_timesheet- everyone with this permission can see all changes of other users timesheets (only via team timesheets)
kimai: permissions: sets: AUDIT: [audit_customer,audit_project,audit_activity,audit_own_timesheet,audit_other_timesheet] maps: ROLE_ADMIN: [...,AUDIT] ROLE_SUPER_ADMIN: [...,AUDIT]
After changing the permissions, you need to clear the cache one more time.
A audit trail can look like this, but each change will be recorded and you might see more entries in a object timeline:
You access an objects audit trail via the data-table “Actions” dropdown:
Records detailed change/audit logs for timesheets, customers, projects and activities and displays them in a per-item timeline.
Create free configurable additional (optional and mandatory) fields for timesheets, customers, projects and activities in various formats.
|Custom CSS Plugin||
|Installation & Update support||
|Recalculate rates plugin||