I´m looking into ODK again, where we had it in production at my former employer - and now introducing to my present employer. There´s an request for getting existing data by QR code or barcode.
A use case would be: I scan this QR code and it provides me a list of data about this specific room. Afterwards the user would then fill in the form(Collect) and add new updated data. The task with requesting existing data, ODK Collect don´t support that. Are there any thougths, ideas, workarounds here? I´m reflecting on if I should build an REST API with Flask, where user would use the QR scanner, getting the information, and then switching to Collect, adding new data.
How dynamic is this scenario? That is, do you have some basic data about the asset represented by the QR code that you need to update once or are there lots of folks that may be updating information about the asset at any given moment?
The part that ODK can't do is automatically creating an updated dataset. This means that the more dynamic the scenario, the more difficult it would be to address with stock ODK tools. This ties in to the issues and possible changes described in ODK ecosystem entity-based data collection table of contents.
The basic concept you can use today is to attach a data file to the form definition that has values associated with each asset. These would be indexed by the code you have in the QR code. Collect would use the QR code value to look up the asset row and populate fields based on those values. Then the user could modify them as needed and submit the form. If further updates are possible, you'd need to update the data file with the new values. You could automate this by pulling all records from Central, building the data file with the latest values for each asset, and uploading it as an update to the form. You can have Collect automatically fetch form updates at some configured frequency.
Where things get messy is if you can have multiple people updating the asset data, especially while offline. For example, Person 1 scans the asset, fills in some data. Person 2 scans the asset and doesn't get the update from Person 1 but also makes some updates. Now Person 2 submits. Later Person 1 submits. You'd need to reconcile those.
If you design your QR codes to encode a space separated string - eg a list of all the things in the room - then you can use the ODK barcode code question type to capture the data, and then process the result as you would, say, a multi-select result using count-selected(),selected-at(), ...
I work professionally with postgresql. If there´s and postgresql database under the hood, then in my view, this is dynamic working scenario - allthough I haven´t tested it yet. So I´m confused about this - and maybe misunderstanding how ODK works with postgresql. In our use case we would migrate existing data into the ODK database and update that by Collect.
There might be a delay on when data (forms) are saved into the database, yes.
If the forms are provided with timestamp attributes , then this I would filter and order my data by.
The default odk user has write permission to add new data to the odk scheme in the database. It should be possible (I hope) to add more users to same scheme an tie them up to new collect users. Nevertheless, the same database can work as an API retrieving the last entered data - that´s just a question of sql statement after (as mentioned above) the data has gone through the filter.
That said - I guess the majority of the users are mostly interested in collecting, then viewing existing data. This was of curiosity if there were others in same boat as us.
If you have software development capability, you are absolutely correct that you can put together a new data attachment file and feed it back into the system. Devices can be configured to automatically pull updated data files. It is indeed a relatively straightforward task for any given individual form definition. What doesn't exist today is a general-purpose way to automatically set this up without software development. There is also no progressive sync capability so field workers would have to download the full updated data set every time it changes.
The threads at ODK ecosystem entity-based data collection table of contents are devoted to exploring formal additions to ODK to support these kinds of workflows without needing software development skills. We are approaching this cautiously because there is a lot of potential for complexity and some of the biggest strengths of ODK have historically been that it is relatively straightforward to get into and workflow-agnostic.