Don't create entities with non-UUID IDs#7096
Conversation
| data class EntitiesExtra(val entities: List<FormEntity>) | ||
| data class EntitiesExtra( | ||
| val entities: List<FormEntity> = emptyList(), | ||
| val invalidEntities: List<InvalidEntity> = emptyList() |
There was a problem hiding this comment.
@lognaturel you've asked for this a few times and I figured this was a good time to give ourselves an API for exposing "invalid" entities. What's the leanest acceptable way you could see these being surfaced to make them useful?
There was a problem hiding this comment.
Summary of a brief conversation we had about this:
- Start with exposing errors from debug builds only, maybe just storing in memory
- Log Submission id, date time, path to the entity declaration, dataset, entity uuid if it exists, entity label if it exists
- Longer term: audit log in the
Project managementProtectedsettings - Standard format for audit items, persisted in db or file
- Send to Central automatically or on demand
- Brainstorming doc
There was a problem hiding this comment.
Ok this will initially write out a log to debug.log in the project directory when the app is in debug mode. The line for an invalid entity will be:
${timestamp} Entities "Failed to create/update dataset=${it.dataset}, id=${it.id}, label=${it.label}"
We can definitely add more detail in, but I think this is a good start.
|
|
||
| @OptIn(ExperimentalContracts::class) | ||
| fun String?.isV4UUID(): Boolean { | ||
| contract { |
There was a problem hiding this comment.
I've not used this before, but it's really cool! It's experimental, but used heavily within Kotlin's lib itself for methods like isNullOrBlank.
2 participants
Closes #7047
I've also added an experimental debug log.
Why is this the best possible solution? Were any other approaches considered?
I decided to move most of the validation we do for entities to the JavaRosa integration. This reduces the uncertainty we have to deal with in the code that creates offline entities and syncs with the server etc.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
There are no real changes other than to the entity create/update parts of the code, so only checks to those features are relevant
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest