ODK Central is a server that is easy to use, very fast, and stuffed with features that make data collection easier. Contribute and make the world a better place! ✨🗄✨
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 https://github.com/getodk/central/issues/682#issuecomment-2226462687, @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.
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.
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 https://github.com/getodk/central/issues/682#issuecomment-2226462687, @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.