Closed cafootitt closed 3 years ago
Each of the 4 types of tasks (https://github.com/OpenSRP/web/issues/171) can be "undone" via the undo workflow (see this issue for more details: https://github.com/OpenSRP/opensrp-client-eusm/issues/15).
Currently, I understand these get submitted as "Undo" events, (e.g. "Undo Looks Good" or "Undo Flag Problem"), but @bennsimon please confirm.
The problem we face is that the mission data export only contains the Flag Problem, Looks Good, Record GPS, and Service Point Check submissions, and not the Undo submissions. So the mobile app user may flag a problem, undo it, but the person reviewing the mission data would just see the flag problem submission.
A) One of the proposals is that, similar to home visits in CHW and immunizations in the child immunization module, we pause the event submission syncing to the server for the period of time that the user is allowed to "undo" the task. In CHW, I believe this is a period of 24 hours. This may be too long for this project, where we want to provide data in as near real time as possible. We could allow "undos" for a shorter period of time, such as an hour.
B) The other approach is to include the "undo" events in the mission data export. This might not be friendly to the person reviewing the data, as they'd have to match up the original task to the undo task by comparing entity IDs, which isn't great. One could also argue that the "undo" option is really intended for accidental clicks, especially on the Looks Good one, in which case, the "undo" would be done right away, which is more aligned with option A, above.
C) Other proposals?
@cafootitt right now we don't have "Undo" event submission. Will implement once an accepted workflow is chosen.
@rowo Yeah we have conformation dialog for both.
I think because the undo will update(revert) task status, the undo event should archive the event that is being undone additionally. This will mean the events even when uploaded on the server will not show on the exports since archived is not by default returned by any APIs.
@cafootitt i think we can go for archiving the event if you're okay with it.
Thanks all for the inputs. I'm happy to go with archiving the event, as it sounds like that's the standard protocol. I will create a separate implementation issue now for this.
Include in the mission data export?
Follow what CHW apps do, and pause the event submission for "Looks Good" until after the edit period is over?