We have notifications set up when dates are changed, and have implemented a change request system whilst restricting access to change the date, however would like an easy view on the main table page of the dates changed, similar to our commentary which is a text field with log edits.

Well one thing that you could try to set up a field called date log which is a another text field set to log changes. And then using form rules set up a rule that says when the record is saved and the date field has changed change the date lock to the value in the field Date. But because this is based on form rules, that means it will not work in grid edit.

We are moving more to custom forms, so that should not be too much of an issues.Sounds promising. Would the text log field, update with a user and date per normal?Having an additional field would allow filter in certain reports to just see the current, so that is also beneficial.Can you please advise what the fom rule would look like?

The form rule would look likeWhen the record is SAVEDand the [Date field] has changedActionChage the value of the field [[my text field set to log chnages] to the value in the field [Date field]And yes, a field set to log chnages, does always record who did the update and the date and optionally the time of day.

Mark, does this mean that logging is inly available on text fields?

A more sure fire way to log data changes is through a Data Change table. Then you just have a button to change the date.You also wont have to maintain a bunch of different forms with their form rules.By creating a date change record, you automatically keep track of who, and when. You can add a bonus feature really easy as to the why.Long term this is the most efficient and cleanest way to track your date changes.I can explain in more detail how to set this up properly if needed.

Is it possible to log edits within a date field?

20 Replies

QuickBaseCoachD
Qrew Captain
9 years ago
Well one thing that you could try to set up a field called date log which is a another text field set to log changes. And then using form rules set up a rule that says when the record is saved and the date field has changed change the date lock to the value in the field Date.

But because this is based on form rules, that means it will not work in grid edit.
ScottScott1
Qrew Member
9 years ago
We are moving more to custom forms, so that should not be too much of an issues.
Sounds promising.
Would the text log field, update with a user and date per normal?
Having an additional field would allow filter in certain reports to just see the current, so that is also beneficial.
Can you please advise what the fom rule would look like?
QuickBaseCoachD
Qrew Captain
9 years ago
The form rule would look like

When the record is SAVED
and the [Date field] has changed

Action

Chage the value of the field [[my text field set to log chnages] to the value in the field [Date field]

And yes, a field set to log chnages, does always record who did the update and the date and optionally the time of day.
ArshadKhwaja
Qrew Commander
8 years ago
Mark, does this mean that logging is inly available on text fields?
- QuickBaseCoachD
  Qrew Captain
  8 years ago
  You can log any field I suppose. It will get logged using a form rule into a text field, but you can write a number or date field into a text field.
MCFNeil
Qrew Captain
8 years ago
A more sure fire way to log data changes is through a Data Change table. Then you just have a button to change the date.

You also wont have to maintain a bunch of different forms with their form rules.

By creating a date change record, you automatically keep track of who, and when. You can add a bonus feature really easy as to the why.

Long term this is the most efficient and cleanest way to track your date changes.

I can explain in more detail how to set this up properly if needed.
- ChristinaHerman
  Qrew Member
  7 years ago
  Hi Matthew,
  I would like to learn in more detail how to set it up.
  thanks for your help.
  Christina
ArshadKhwaja
Qrew Commander
8 years ago
Thanks. I am already using QB Actions. Is this what you are referring to?
- MCFNeil
  Qrew Captain
  8 years ago
  No, I'm saying you can make a table called "Date Changes". And use that to keep track of your changes, and who (and why if wanted)
  >
  Just one Field;
  "Date"
  
  A second field would be needed if you had a "Why"
  >
  Each 'Project' can have many date changes.
  >
  Summarize Max Record ID
  >
  Pass new max RID as lookup
  >
  Summarize Date where max RID = Record ID#
  
  Now you have your log of date changes with time stamps and record owner.
  
  Much cleaner and more scalable if you have multiple dates that need to change. Also gives you much better reporting outputs. (ie. How many times this date has changes, most frequent cause of Date changes, who makes the most changes, etc.)
- ArshadKhwaja
  Qrew Commander
  8 years ago
  Got it. Thanks. Yes I am using the same approach for summering some info. So Understand the concept. Thanks.
ChristinaHerman
Qrew Member
7 years ago
Hello Matthew,

out of what you wrote above I am not able to reapply it. Could you please send me a more detailed description of how to set this up please.
Just one Field;
"Date"
A second field would be needed if you had a "Why"
>
Each 'Project' can have many date changes.
>
Summarize Max Record ID
>
Pass new max RID as lookup
>
Summarize Date where max RID = Record ID#
Now you have your log of date changes with time stamps and record owner.
Thanks a lot,
Christina
QuickBaseCoachD
Qrew Captain
7 years ago
Christine,

Matthew is suggesting that you create a child table of dates and make your date updates there. Then you will have a very clean audit trail of the date changes.

Post back if you need help with that.
SuscoImplementa
Qrew Trainee
7 years ago
Thanks to QuickBase webhooks it's now pretty easy to create history tables where you can log old record values. Let's say you have a helpdesk Ticket table, you can create a TicketHistory table and use webhooks to create a new record whenever a Ticket is modified
QuickBaseCoachD
Qrew Captain
7 years ago
Good point, it now that we have ACTIONS we can set up a log table that way, and not need to struggle though the Webhooks Syntax. So using that method, you just update the date normally and the ACTION will do the logging.
- MichaelKefauve1
  Qrew Member
  6 years ago
  I am currently looking at a similar application where I want to track/log changes to a date field. I understand the approach of using an action to update a child table, however, I have 25 different date fields that I want to track. So, that means 25 different child tables, right? Would that be more efficient, or would it be more efficient to create a separate log field for each date field, each with it's own form rule? Also, is there any way to not show the user ID and date of entry in the log field, i.e. just display the list of sequential entries?
- QuickBaseCoachD
  Qrew Captain
  6 years ago
  You would not need to have 25 child tables as you could have an identifier in the log table to identify the field.
  
  But maybe in your case, yes set up 25 log fields and 25 form rules to populate the log fields.
  
  The there is a formula I can help with to count the # of updates. So you will need 25 formuals. Then you will need 25 more formulas to to parse out the most recent date update.
  
  I think if I had to that somewhat ugly project I would use a child table. you can have I think 20 Automations per table to trap 20 date field changes and 10 Actions to trap the remaining 5.
  
  Otherwise you need to use a webhook to log all 25 when any of them changes and then using an automation delete out the date changes that did not change.
  
  This is just an overview - due to the large # of fields to be tracked its not a trivial project.