I suggest you ...

Record Versioning

With the ability to edit a record open to a wide audience, it would be nice to be able to recover from either a malicious edit, or simply an incorrect edit, by reverting to a prior version of the table row.

If you think about the way a Wiki works, the past versions of the definition are available so that changes can be rolled back to any prior version of the record.

This may need to be a privileged function as well - available only to a specific user level.

137 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    robclayburnAdminrobclayburn (Admin, fabrik) shared this idea  ·   ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Orbis TertiusOrbis Tertius commented  · 

        I'm not sure how wikis do it, but the most reliable way I've found to do this is with separate history tables that tracks insert/update/delete queries on a given data table via triggers. It's important to put the logic in triggers, rather than in the application, since frequently the sort of behavior that prompts an audit isn't done through the official means provided by an application. Typically the history table is identical to the data table, with the addition of a numeric or datetime column that when combined with the original table's primary key makes a unique composite key, to track changes to individual in sequence.

        See 'Chapter 8 - Retaining a Tracking Log' here: https://www.cs.arizona.edu/~rts/tdbbook.pdf

        That uses datetime columns as the 'sequencing' column. A *much* easier way to do it is explained here: http://stackoverflow.com/questions/12563706/is-there-a-mysql-option-feature-to-track-history-of-changes-to-records/12657012#12657012 , which takes advantage of some features MyISAM has when doing composite primary keys.

        I think Fabrik could easily create and track those triggers with some information_schema querying, and even provide a way to update them when the schema of monitored tables changes. This would be a very nice feature for Fabrik to offer, to be able to just click a checkbox and have all the history tables and triggers created automagically, and maintained behind the scenes.

      • S_KellyTTS_KellyTT commented  · 

        This would be an excellent addition. Much needed.

      Feedback and Knowledge Base