In the current architecture (Jan 10, 2022), each time a REDcap event is processed, an attempt is made by the ETL subsystem to interpret that event and apply any database changes that can be inferred from REDcap to the VBR PgREST database. This must be changed so that once a record has been updated by the VBR API, it can no longer be updated by REDcap-triggered ETL processes.
This will require:
Extending the database schema to include a lock field defaulting to False
Extending the ETL workflows to check the status of the lock field before proceeding to update the database
Extending the API to lock records after it edits them.
In the current architecture (Jan 10, 2022), each time a REDcap event is processed, an attempt is made by the ETL subsystem to interpret that event and apply any database changes that can be inferred from REDcap to the VBR PgREST database. This must be changed so that once a record has been updated by the VBR API, it can no longer be updated by REDcap-triggered ETL processes.
This will require:
False