I have a scheduling app that has a "Schedule Date" field. I would like to be able to capture and stamp that date on record open to another field called "Previous Schedule Date" so that when the Schedule gets changed (due to reset or no show) I can use the original date to count resets and no shows? We tried doing this manually but compliance was very low.
I would like to automate this and take it out of the users hands if possible. I want them to just change the date and set up counters to determine if it was a reset or no show.
Set up a text field called [Schedule date log] and set the Field properties to Log Changes.
Make a form rule that says
when the record is saved
and the [Scheduled date] has changed
Change the value in the field [Scheduled date log] to the value in the field [Scheduled date]
That should give you an audit trail in indelible ink of all the Scheduled date changes.
Keep in mind that when the new Mercury user interface comes in in the fall, we don't really know if and how these non-native customizations will work.
Hence I always feel that it is safer to stay with a native solution where there is one.
And there is nothing anyone can do to stop you from using Service Workers because there is no Content Security Policy or other configuration to block it. Service Worker for the win!
̄\_(ツ)_/ ̄ ̄\_(ツ)_/ ̄ ̄\_(ツ)_/ ̄ ̄\_(ツ)_/ ̄ ̄\_(ツ)_/ ̄ ̄\_(ツ)_/ ̄ ̄\_(ツ)_/ ̄
You can edit the record or create your own records. You would have to modify the script slightly to manipulate a date field but it is a simple change. I simplified things and wrote the code without using jQuery and without formally testing for what page the user is on (since the _fid_* elements would not be present on other than edit or new pages).
Off the top of my head I thought the old value of a date (eg name=_fid_oval_6) was stored in a different format than the human readable date that is displayed in the field. A spot check appears to prove this wrong so I think you can use the same code after all.