Correction: This post previously used q
as the search parameter for finding a specific UUID. The correct parameter is query
.
This isn’t particularly easy, but possibly you could write a tiny web application that accepts requests containing a submission UUID and then:
- Gets the ID for that UUID by making an API request to KPI, using token or HTTP basic authentication. A sample URL would be
https://kf.kobotoolbox.org/api/v2/assets/aLQD8NJG6HCNZQw5TZdyZX/data/?query={"_uuid":"952d24f5-26d0-4cc1-9c30-09b997e9703e"}&fields=["_id"]&format=json
; - Parses the output; you might have multiple IDs per UUID if a data-collection client behaves badly, e.g.
{"count":2,"next":null,"previous":null,"results":[{"_id":38149357},{"_id":38149366}]}
. Hopefully that never happens under normal circumstances! - Takes the ID and requests an Enketo edit URL from KPI (authentication still required at this point), e.g.
https://kf.kobotoolbox.org/api/v2/assets/aLQD8NJG6HCNZQw5TZdyZX/data/38149366/edit/?return_url=false&format=json
; - Parses the output, e.g.
{"url":"https://ee.kobotoolbox.org/edit/::iinbheUI?instance_id=952d24f5-26d0-4cc1-9c30-09b997e9703e&returnUrl=false"}
, and redirects the requesting user to the edit URL. These edit URLs do not need any authentication.
Maybe you could simplify this by referencing submissions by ID instead of UUID when you correspond with your coordinators. You’d probably still need steps 3 and 4 to happen in an automated way somehow, since as Martijn mentioned the edit URLs expire very quickly.