Is it possible to know about pending tasks from forms?

Technical Support
,
1

This relates to Commodity workflows and is based on conversations with @Jane_Katanu and @Jenny (cc: @philip) and is a potential workaround for How to access parents summary information from an App form?

TL;DR

CHWs receive a Task from their Supervisors that will replenish the CHW’s stock counts when the CHW completes that task. Often, CHW’s have received the physical stock but do not immediately complete the Task, so the app doesn’t know they have this new stock. Then they provide service to a patient and stock levels can go negative in the app because they haven’t received it in the app. One consideration was having some notification at the start of a form if there is a certain type of pending task. Is it possible to prevent a CHW from proceeding in a form if a certain type of task exists?

Need more context? :point_down:t4:

For the sake of discussion, imagine this hierarchy and a scenario where a CHA has replenished a CHW’s stock of Chlorine tablets, then the CHW visits a household and needs to give them Chlorine tablets.

CHU (Primary Contact = CHA)
→ CHW Area (Primary Contact = CHW)
----> Household
--------> Patient

Current Predicament

  1. CHW has 0 Chlorine tablets on hand (physically and in the app)
  2. CHA supplies the CHW with 10 chlorine tablets (physically and by submitting a Commodity Supply form)
  3. CHW receives the physical goods and a Commodity Received task that is intended to update their stock level
  4. CHW does not complete the task, so they have the physical goods but the app still thinks they have 0
  5. CHW completes a WASH Visit form for the household and tells the app they have provided 5 chlorine tablets
  6. CHW now has 5 physical chlorine tablets, but the app thinks they have -5

Is it possible at step 5 to notify or prevent the CHW from proceeding if they have a pending/incomplete Commodity Received task?

2

:thinking:

Short answer is no, I do not think there is any clean way to prevent form loading/completion based on pending tasks.

I assume the Commodity Received task is being triggered by a report doc that gets associated with the CHW Area. And then the WASH Visit form is getting filled out for either the Household or the Patient. If this is the case, then there is not really any way I know of to have logic in the WASH Visit form depend on the Commodity Received task. @inromualdo and I have discussed this at length in the past, and the main sticking point is that there is not really any way for forms for one contact to access the contact summary for another contact.

If we had the ability in a form to load the contact summary for one of the parent contacts into the form, that would allow for some possible creative solutions to this challenge. Perhaps you could have logic shared between the CHW Area tasks and the CHW Area contact summary that would let the contact summary reflect that a Commodity Received task was pending…

Ultimately, though, it might be better to consider if we need to make a cht-core change to support restricting access to some forms when there are pending tasks.

1 Like
3

Re: Shared contact summaries

Persisting contact-summary results is something @gareth and I have discussed quite recently, but for a different application (we were thinking of persisting a snapshot of a contact-summary before documents were permanently purged), the result of our conversation was a rabbit-hole of what-ifs, and we eventually stopped.
I think this is worth thinking about in the future, but implementation details are quite complex to get right (when do we recalculate? what does recalculate mean? do we keep old snapshots?). We have a recalculation mechanism in tasks, which is quite necessary, and even though it was designed and thought through and revisited several times across the years, it still raises issues.

I think persisting and sharing contact-summaries is too complex to consider as a solution here.

Re: prevent from opening forms when tasks are pending

We have no mechanism for this either, but I think this is quite a smaller bite than the above.
I’m thinking about two options:

1. Try to prevent from opening the form

We evaluate this form context, which is declared in the form document (not the form XML) as a property. The context is not evaluated when opening tasks, so if this is though tasks, then this will not work!
This context has access to the following information:

  • the contact that the form is opened for (this presumes that the form is opened from the contact detail page)
  • the contact summary of the above contact
  • the user’s hydrated contact document

I’m thinking if appending a tasks property to the user contact, or just as a new property that gets in the form context evaluation function, that contains a list of tasks that are pending for the user’s contact and the tasks that are pending for any of the user’s facilities.

This has the potential to make the form context property quite complicated (as it would require searching within those tasks to not find the one task)

2. Try to prevent from progressing in the form

This is less clean.
The form gets access to:

  • current user’s user settings, as-is, through >inputs>user
  • form subject contact summary

I think the only “clean-ish” way would be to attach pending user/facility tasks (same task load as above) as a state to the user’s settings property that gets passed to the form. This means that some calculation will have to iterate over an array of inputs to check whether a task exists, and prevent progressing the form if it does. I’m not a form expert to know how easy this is. Maybe this is exactly what our extensions library is for :slight_smile:

I think this has the advantage to work regardless of where the form is opened from.

I think both solutions are quite equivalent in implementation complexity, because they both involve writing some function that gets the same task documents, and attach them to some object that already exists that gets passed to the form (whether to the form calculation or the form context).

2 Likes