Surface entity processing errors as conflicts #688
Labels
backend
Requires a change to the API server
enhancement
New feature or behavior
entities
Multiple Encounter workflows
frontend
Requires a change to the UI
An error can occur when a submission is processed for entities. For example, a submission that tries to create an entity, but doesn't specify a UUID will result in an error. We show entity processing errors on the submission detail page.
However, it's easy for the user to miss these errors. We don't indicate in the submissions table whether a submission had an entity processing error, so unless the user visits the submission details page, they won't see the error. That's in contrast to entity conflicts, which we show in the entities table and elsewhere in Frontend. The idea of this issue is to surface entity processing errors as entity conflicts wherever possible, increasing their visibility.
Some entity processing errors refer to an existing entity. For example:
We could show these errors not just on the submission detail page, but also on the entity detail page. They would be counted as entity conflicts so that users would notice them from the entities table and other places. As with conflicts between entity updates, it would be possible to mark these errors as resolved. When an entity is marked as resolved, any current entity processing errors associated with it would no longer be shown as conflicts. (A future processing error about the entity would cause the entity to enter a conflict state again.)
At #682 (comment), @ktuite suggested handling one case involving offline entities as an entity processing error. It'd be great if that error were surfaced in more places so that the user doesn't miss any entity data that's been collected. If this issue were implemented, the error would be surfaced as a conflict.
The text was updated successfully, but these errors were encountered: