Flow 2-3: Add step to find Primero `referral` & update status

[aleksa-krolls]

Background

Flow 2-3: Currently sends UNHCR caseworker’s decision back to Primero (see sample decision state that Progres sends to the OpenFn Inbox)

Current job uses getCases(...) to find the case record_id using case_id, and then updateCase(...) to update case status. Now we are NO longer using updateCase(...) operation, because we need to update referral status (not case status).

To replace this step^ with a flow where we (1) get the matching referral, and (2) update the referral with the decision status.

Request

See here for the data flow described below: https://lucid.app/lucidchart/invitations/accept/inv_6c512b10-f0ad-4e59-9c47-2adeb124ce37?viewport_loc=-144%2C186%2C2684%2C1352%2C0_0

Updates for job Flow 2-3 will need helper functions... see the 2 issues I created in the language-primero repo.

1. Replace updateCase(...) with getReferrals(...) to GET a list all Referrals created for our case GET /cases/:id/referrals See sample JSON response.

NOTE: to map case id, Progres will send us "progres_orgreferralid": "{case_id}#{service_id.substring}" (see example).

• case_id: You will need to parse the string before the # to extract the case_id (e.g., 43597a1b-fff9-4602-99d7-bcc0bc8a917b).
• service_id: Then parse the string after the # to extract the last 12 characters of the service_record_id (e.g., 96aa797f5ee7)

2. fn(...) transformation block: We then loop through these referrals from the response until we find the referral where the last 12 characters of the “service_record_id” match the service_id (see above) parsed from the JSON decision sent by Progres.

So if Progres sends us "progres_orgreferralid": "43597a1b-fff9-4602-99d7-bcc0bc8a917b#eb097be51d89" This is the matching referral to update. See L4 for the referral id.

Once we find the matching referral record to update, pass the full referral id onto the next operation...

3. updateReferral(...) to PATCH an update to the referral status PATCH /cases/:record_id/referrals/:id See sample JSON payload for request body

state.json

Progres/DTP - Use the certificate Primero - See LP for Primero Gambella Demo (openfn_testing)

Sample decision state from Progres/UNHCR: https://github.com/OpenFn/primero-progres/blob/master/sampleData/progresDecision__flow2-3.json

For testing, you can use this case's ids that has related referrals to test:

 "case_id": "f59e880e-d58f-4b68-ba6e-e0616a49aefd",
 "record_id": "406b539a-e662-425e-810b-47e4fa7da496" (sometimes referred to as "id" in primero docs)
"id": "4c58d02f-3182-4006-b2fe-96aa797f5ee7" (referral id)

adaptor

Primero adaptor Primero API Docs

expression

https://github.com/OpenFn/primero-progres/blob/master/jobs/2.c.uploadDecisions.js

[lakhassane]

@aleksa-krolls Im running tests here but I have a suggestion. Instead of removing only updateCase we can also remove getCases(...) and use directly getReferrals() because getReferrals itself goes to fetch the case first. So no need to prior fetch the cases.

One problem with that is if there is no case we will not thrown an error as previously but only log 'No cases found'

[lakhassane]

@aleksa-krolls tested and working locally. Let me know please when we have a message in prod that I can use to test in prod.

Also Im updating referral using decision object that was built previously in the job. Should we still keep that one or build another one?

[aleksa-krolls]

@lakhassane

1. Re: your suggestion - I don't think we can skip the getCases(...) step because I think we need to use the case_id to look up the case's record_id to map in # 2 below. Unless your testing is showing otherwise or if you managed to make updateReferrals(...) work using either case_id or record_id?? Let me know if you want to discuss.

2. No, good catch. When we update the referral, it looks like we need to replace the decision object with a payload like this. Mappings should be:

   "data": {
   "status": data.progres_reviewdecision === '125080000' ? 'accepted' :
        data.progres_reviewdecision === '125080001'  ? 'rejected': data.progres_reviewdecision, 
   "id": {matchingReferralId},
   "type": "Referral", //hardcoded
   "record_id": {record_id}, //different case uuid; not the same as case_id
   "record_type": "case" //hardcoded
   }

[lakhassane]

@aleksa-krolls updated decision accordingly

[aleksa-krolls]

@lakhassane Failing on prod... what adaptor version should I be using? Please update on prod and feel free to re-run... Job: https://www.openfn.org/projects/p5am6e/jobs/jyx9bg Run: https://www.openfn.org/projects/p5am6e/runs/0615483f-fba1-746a-bbe9-bd3619cccbef

[lakhassane]

@aleksa-krolls v2.3.1. I re-run https://www.openfn.org/projects/p5am6e/runs/06154853-b1a1-723a-a9e5-f29a3040ae1b

However no case matching that case_id?

[aleksa-krolls]

@lakhassane test data issue... we're in business!! https://www.openfn.org/projects/p5am6e/runs/0615485c-664a-76f1-8049-4b13281edea3

@daissatou2 looking the like the new referral flow will work :D. Tomorrow we'll walk through testing with Rob, and then you and I can do some more testing over the next couple of days