Script: Trigger new entry in child form or table

[Chris Ju]

Hello everybody,

is it possible to trigger a new entry in a child form (or table) by changing any field in the parent form?

Then it would be ideal if the old value of the changed field could be transferred to the newly created entry in the child form (or table).

The aim is to track changes and preserve historical values.

Thanks in advance
Chris

[Brendan]

Hi Chris,

Sure, you can do this.

Add a Field Script to your form that watches for the value of another field that you’re wanting to change. Then call the record.addRecordToField(someRecord, field_id); function to add a record to your Table or Link to Form field.

You’ll have to create the someRecord record first, then populate it with your values, then call the above function.

Then call form.saveAllChanges();

Thanks!

Brendan

[Chris Ju]

Thanks, Brendan.

Add a Field Script to your form that watches for the value of another field that you’re wanting to change.

Can i watch all fields and if one was changed get the field name to pass on to the new entry in the child form?

(I hope it’s understandable ;-)

Thanks,
Chris

[Brendan]

Calling var field_1 = record.getFieldValue(field_1); will get you the value for field_1. That’s how you watch for the value of a field. You would have to list every field in your form like that in the script to watch them all.

I understand what you’re wanting to do. But Tap Forms wouldn’t tell you which field was just edited. For every field you watch, Tap Forms would just give you its current value. Then you’d have to log that to your Table field or Link to Form field.

[Chris Ju]

Thanks a lot, i’ll try that (it’s more complicated than i thought :-/) and give here a feedback. Maybe it could be useful for someone else.

[Sam Moffatt]

A thing I thought about a while back for detecting the change is to create a script that watches just one field each and referred to itself to detect changes to the field. Then you can use runScriptName with some variables set already to have a common form script to handle the specific logic you need. That was only for fields in the same form, I’m not sure how well it’d work with table/child records propagating to the parent records but I think it should work for detecting changes within the same form. You could use something similar to call into the parent from the child for a link to form case, I’ve not spent as much time with table fields to know if that’d work.

An example of a script field that refers to itself to retain historic state is in my checkbox flip flop script.

[Chris Ju]

Thank you Sam for your contribution. I tried your scripts (Form Logger, Logger, etc.) and came up with the following idea:

Instead of historical values (by triggering new entries), the old and new values could be written to a log file (ideally on a log server), e.g.: modification date / form name / field / deviceName / old value / new value …

In the case that nothing is changed, log entry should not be made.

Do you think that would be possible?

Thanks
Chris

(I’m unfortunately an absolute beginner in scripting, so your help would be really great …)

[Sam Moffatt]

If you check out my GitHub there is a tftools GIT repo with a number of PHP scripts that should run on any recent Mac (tested on High Sierra, semi frequently on Mojave and also on Ubuntu 18.04 with PHP 7.2). There are two backup tools, the first is a simple polling operation that grabs records as they change at the polling interval and the other one of those is a backup tool that uses CouchDB’s revisioning properties to try to retrieve all changes. You can use eithre to get a copy of almost all changes (assuming sufficient polling interval) made to a Tap Forms document. I generally use the simple one with an hourly snapshot interval. Caveat is you need to enable sync to CouchDB for it to work properly but beyond that it is stable (in theory you might be able to skip the CouchDB requirement but you’d have to track down the sync port from Tap Forms each time you open a document). I personally use it to keep an extra backup copy that let’s me also look back into time to pull back stuff that I break. Downside of this is that it’s all inaccessible from Tap Forms, you’d need some sort of bridge web service to get at that data from a script inside of Tap Forms.

If you wanted the data to be accessible inside of Tap Forms, you could create a second form within Tap Forms to store the changes. You would need to store a shadow copy of the record with the old values and you would need another form for your log with just the differences. The shadow copy could be an exact replica of your base form but that would be a pain to keep in sync and would result in a duplicate form for each form tracked. That’d be a little expensive but does have the advantage that you could debug it reasonably easily because Tap Forms would render the shadow copy. That leaves you with a form that would store a serialised copy of the records in a simpler form which would have the advantage that you could store what ever you need (curiously at that point you’re recreating a database like CouchbaseLite on top of Tap Forms which is running on CouchbaseLite). You need the shadow copy because Tap Forms doesn’t maintain the earlier copy so you need to do so to get the old version of the record. From there you could use field scripts to monitor all fields, deserialise the shadow copy, compare all of the fields, update the shadow copy with the new values that have changed and then persist the change to a logging form. The logging form I could see as having fields for Form ID and Name, the Field ID and Name, a field for a serialised copy of the old value and a field for a serialised copy of the new value.

You could leverage an external set of tooling to also write back into the CouchDB the change log and maintain the shadow copy outside of the Tap Forms database. That might make sense to be able to aggregate a number of related edits together into a single logical change because without the edit/save button enabled, every edit is automatically persisted and replicated to CouchDB (this is, in general, a good thing). This would remove the need to have a field scripts inside of Tap Forms to duplicate the data but would mean you’d be reliant on that infrastructure working.

[Chris Ju]

Thanks a lot! I will try to implement your hints / advice … and hope it does not stop at trying ;-) …

[Author]

Posts