Add `unique_identifier` to mappings

[aleksa-krolls]

https://github.com/OpenFn/unicef-cambodia/blob/11a88f6e89917e56289cd02151e9e8da2355a1c3/jobs/f2-j2-upsertCasesToPrimero.js#L401

1. Make this change per the API documents to add unique_identifier: case_id
2. Please comment with documentation on known vulnerabilities with this solution approach to the unique identifier issue

[taylordowns2000]

For the record, while we're a little worried about the underlying mechanics that necessitate this duplicate information, so long as the logic that's happening on the Primero side (which we can't see) is sound and does what it's intended to do, the only real risk in building and sending this duplicate information is the risk that later changes to the job (or to Primero) will be accidentally made to one, but not both, of these fields. We're doing our best to mitigate that risk by establishing the primeroId function, but don't have visibility into how Primero is working with these two, differently keyed but preferably identical values. Best case scenario, changes around this feature take twice as long, worst case scenario, they get out of sync.

From me:

Hi +alberto.espinoza@quoininc.com , is the idea that there are certain implementations of Primero where you'd like to be able to enter two different records with the same case_id? If so, we're understanding that we are supposed to mark each request with unique_identifier, specifying that we would not like to create duplicates for this particular implementation. Is this correct?

We see the change to the API documentation. is that new field unique_identifier to be set to true/false or are we to send the same value that we're sending to case_id in that field? (If so, what's the business value to sending that same case_id twice, with two different keys? Should we instead be using a boolean, or maybe specifying which field we'd like the constraint applied to: e.g. "unique_identifier": "case_id")

Thank you!

From Pavel

+taylor@openfn.org We would like you to simply duplicate the value of case_id in unique_identifier. Having the unique_identifier populated guarantees that a POST will be an upsert, with a query performed against the unique_identifier.

You are right, originally those values really were separate, but that is no longer true. The business value has faded, but the API logic remains.

I am reluctant to have Alberto make any significant changes to the v1 API because the medium term strategy is to deprecate it.