We are deploying a solution to a company in healthcare. Health inspection requires serious adit trails on user edits to be able to track back who changed what.
For this we planned to use the build in trailing functionality in Servoy security. We found out however that this feature is linked to eacht table/usergroup combination. In our framework the client can create their own usergroups. We could not find a way to turn on trailing for each table for a newly created usergroup.
Can this be done, or is it a new feature?
Alternatively we explored if we could use table methods but found out edits through a relation do not trigger table metheds in the related table!
We have a group called “tracking”. Every user on the system always belongs to that group, no matter what. We do not allow deletion of that group either.
you can use onRecordInsert/onRecordUpdate/onRecordDelete events on the tables.
This is more programming work to be done, but as you have to do the programming, you can also set the rules…
ron@ambitius.com:
Alternatively we explored if we could use table methods but found out edits through a relation do not trigger table metheds in the related table!
With table methods I assume you mean Table Events. These events should always trigger (also over relationships) when you edit a record.
So if this doesn’t work for you like that then this would be a bug.
The only exception to this rule is when you are using the rawSQL plugin or when you use the foundsetUpdater’s performUpdate function.
This last function will effectively send 1 UPDATE statement to the backend database to change many records. Since Servoy can’t see what records that would be it can’t trigger/trace them.
This limitation is also present in the built-in audit trail.
Another limitation (I believe it’s still the case in version 5) is that the built-in audit trail is not database-transaction aware.
So if you start a db transaction, change a bunch of data and then rollback your transaction then your audit trail log still holds all those changes.
I am planning to file a case for this. I think Servoy could use a transaction on the logserver connection when you start one and keep track of them so that if you commit or rollback your transaction that the logserver transaction also gets committed/rolled back.
Now, If you really want an ironclad audit-trail then database triggers on the tables is the way to go. It will log any record you touch by any query and by any database client (Servoy or otherwise).
But of course this is less (to use an understatement) portable than Servoy’s built-in table-events or audit trail.