Kimai2: Feature request - prevent manipulation of the data stored in the timesheet

[hmr-it-jr]

Is your feature request related to a problem? Please describe.
Yes, it fixes a possible manipulation of the data stored in the timesheet.

Example: A company has an employee which has to work 40 hours peer week. At the end of the week the employee notices that he has worked only for 39 hours. At the moment it's possible that the employee adds 12 minutes to every day of the week and no one would notice it - the employee now "has worked" 40 hours.

It's just an example. It's possible to edit everything without someone noticing it.

Describe the solution you'd like
If someone tries to edit an entry in the timesheet which has been saved and stopped recording already X (make it dynamic) hours ago an email should be generated to the admin or a defined user that a user has edit an old entry. In this email there should be the original entry vs. the edited entry. Maybe it's a good solution if the user has to provide a reason why he wants to edit this entry. This reason should be in the email, too. If the email has been sent the edited data should be stored and saved.

Describe alternatives you've considered
Maybe it's better to send the email and put a link to verify the change. If the admin or defined user clicks on that link the change is approved and as long as the admin or the defined user isn't clicking on the link the old version of the entry is in the database and visible for the user who tried to edit this entry. If the edit is approved an email to the user who edited it should be generated that you notices it was approved.

Additional context
In Kimai1 we had a cronjob overnight which made a hash over the new rows of the day and stored the Id of the timesheet_entry and the hash in a table. After hashing today we compared every entry in the timesheet with the table which contains the hashes. If a entry has been manipulated an email has been generated.

[kevinpapst]

How do you manage "add entries"? Users could still "manipulate" the recorded time by simply adding wrong times for new entries. To be devils advocate: users could "forget" to clock-in for some arbitrary days during the month and simply add the missing times to these days at the end of the month.

I think the way you described it is very focused on one use-case. But I totally understand the need for a permission system and I already have a plan in my head and will do a proper writeup later, just as a rough draft:

• Every user has a role (thats already the case)
• Roles inherit each other (that is already the case and could be changed by re-configuration as well, its just not yet documented fully)
• There is a set of permissions (like admin_users, edit_own_timesheet... some you which are now available in Kimai 1)
• Permissions will be given to roles, something like:
  
  
  
  • ROLE_ADMIN: admin_users, edit_other_timesheets
  
  
  • ROLE_TEAMLEAD: edit_own_timesheet, approve_team_timesheets, create_invoices
  
  
  • ROLE_USER: start_entry, stop_entry, edit_own_timesheet
  
  
• These definitions are kept in a config file (for now)

If we would have something like that, you could simply move the permission "edit_own_timesheet" from ROLE_USER to ROLE_TEAMLEAD. Thats actually what I wanted to work on in one of the next milestones.

If you want you could think about the required permissions and write them down as simple list with a short explanation what each of them should handle.

The emails would require some kind of workflow system, which should be discussed in a separate issue. I don't see that feature to be part of the Kimai core functionality (in the near future), but it could be possible to add it as extension.

[hmr-it-jr]

You're right, users could still manipulate it with adding times and not changing the entries which are already in the database. So what about dealing it the same way with providing a reason why the entry needs to be added if it's already X (defined) hours past now.

Example: defined is 12 hours for editing without providing a reason - so if a user tries to add an entry which is 13 hours ago from now he needs to provide a reason for it as described in previous post.

I want that the user can edit his own timesheet at any time he wants - I just want to know what is happening. So just adding permissions won't solve the problem of detecting manipulations. Don't you think so?

[kevinpapst]

Hm, that would require some kind of audit log then.
Okay, I might have missed the original point then. Well, only sending an email on an change could be easily solvable with a customer TimesheetListener. Basically 1 class in an extension should be able to detect a change.
But adding a reason field to the form might be slightly more complicated. I will think about how to do that.

[hmr-it-jr]

I'm totaly fine with the easy solution of sending an email via a TimesheetListener. The reason field is just nice to have but not a must.

[kevinpapst]

With the latest addition of configurable permissions you can now disable editing existing entries.
This is not completely what you need/want, but may solve the main use-case.

[tanius]

For those looking at this issue, it may be useful to know that there is now a commercial plugin providing this functionality, called audit-trail.

[kevinpapst]

@tanius thanks for cross linking. Just to clarify, the plugin does not prevent the changes, it can just display them afterwards.

[kevinpapst]

I think with the existing plugin and the option to disallow editing own entries, this can be closed.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. If you use Kimai on a daily basis, please consider donating to support further development of Kimai.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. If you use Kimai on a daily basis, please consider donating to support further development of Kimai.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. If you use Kimai on a daily basis, please consider donating to support further development of Kimai.