Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surface entity processing errors as conflicts #688

Open
matthew-white opened this issue Jul 18, 2024 · 1 comment
Open

Surface entity processing errors as conflicts #688

matthew-white opened this issue Jul 18, 2024 · 1 comment
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

Comments

@matthew-white
Copy link
Member

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:

  • A submission tries to create an entity with a UUID that is already in use.
  • A submission tries to update an existing entity with a property that isn't on the entity list.

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.

@matthew-white matthew-white added enhancement New feature or behavior backend Requires a change to the API server frontend Requires a change to the UI entities Multiple Encounter workflows labels Jul 18, 2024
@matthew-white
Copy link
Member Author

We were considering working on this as part of v2024.2, but we've decided to wait on it. Instead, we're going to track the number of entity processing errors that users encounter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

1 participant