View the change history of the field.

Got something cool to share with AppGini users? Feel free to post it here!
Post Reply
espo
Veteran Member
Posts: 98
Joined: 2013-03-01 12:55

View the change history of the field.

Post by espo » 2015-11-17 09:52

Hello to all. I tried various ways but I could not understand how to view the history of changes in the page display.
I have created a VarChar field with a value as automatic image I have attached.
Each time data is modified I get date and name.
I would like to see a video history of all the times that a field was changed and who changed.
You can help me solve?
Thanks a lot.

Image

Image

User avatar
shasta59
AppGini Super Hero
AppGini Super Hero
Posts: 231
Joined: 2013-01-08 19:40
Location: Calgary, Alberta, Canada

Re: View the change history of the field.

Post by shasta59 » 2015-11-17 16:46

What version are you using? It is usually a good idea to put the version on the first line.

Ex: Using version 5.42

Now onto your question. Yes this can be done but the current build in tools only show date/time changes not what data was changed. For that you need to write custom code which does the following:

(I have done this already but as a client paid for the work it is their property and cannot be distributed - that was the agreement we struck)

That said have code do this:
When a record is selected I have all the values written into another set of variables to be used in a bit.
Then when the record is saved I have code compare the new values to the old values. Any that are different are recorded into another table and linked to the id of the record in the first table.
The second table has the same fields as the original table but only the original values are written into it. You can then look at the second table and, at a glance, see a progression of changes. My code also writes who changed it, when, and what their ip address is. Since the current value is stored in the original table there is no need to store it in the table which records the changes.

I then wrote some code, when the current record in the first table is selected, to show all the change below that record for that record.

Hope this makes sense. If I come up with another way, different from my first method, I will post that code.

Alan
Calgary, Alberta, Canada - Using Appgini 5.50 -

grimblefritz
AppGini Super Hero
AppGini Super Hero
Posts: 336
Joined: 2015-12-23 16:52

Re: View the change history of the field.

Post by grimblefritz » 2015-12-31 23:22

I've not done this with appgini, but in other environments I have coded the edit routine to create a linked list. For example, if record id 5 is edited:
  • when edits are "saved", mark record 5 as "frozen"
    insert a new record that is a copy of the modified record 5
    capture the id of the new record (lets say its record 12)
    in a "next_edit" field in record 5, write 12
    in a "prev_edit" field in record 12, write 5
    the big one - finding all the foreign keys pointing to record 5 and changing them to 12
    (or, you can always point to the first version and have the code walk forward to the latest version as needed)
This gives you a full audit trail; however, it is very fat. If you have a hundred fields and edit only one, you still create another record with 100 fields. On the other hand, if space and record counts aren't a concern - and with most appgini apps I suspect this is true - then it is very simple and very robust. There's not much overheard as you're not having to compare every field, write out field level change history, etc.

To impement, of course, the overall system has to know several things, including:
  • ignore frozen records in normal operations
    hide the frozen and next/prev_edit fields in tables and forms and reports
    UNLESS a "show audit trail" mode is set
There's also a decision needed to control how deletes work. Does a delete of record 12 also delete all previous edits? Or does a delete revert to the previous version? Or do you implement two commands - "delete this record" vs "revert to previous version"?

The other alternative, of course, is to simply maintain a set of mirrored tables - customer and customer_hist. When you create a changed record in customer, write the original into customer_hist. The history table needs some form - a linked list, a timestamp, etc - to retain the order of edits. Also, in history there cannot be a primary key and the required and unique attributes should be removed. The upside is, there's little or no rework of the primary logic. Due to the table extensions and lack of relational elements, the history tables simply float out there and can be ignored. Except by custom routines dealing with audit views and reports, that is.

Post Reply