1. What is the issue? Please be detailed.
(I feel like I've seen mention of this somewhere, but can't find it quickly on the forum or in github. Please merge threads as needed.)
This only applies to draft forms.
For a draft form that reads from entity lists, if a list is updated after adding the form to the device, the draft doesn't see the changes (eg add an item / change an item / remove an item).
Resetting the form and redownloading doesn't fix this.
Deleting the form and scanning the QR again also doesn't fix this! (app cache reset in device settings not tried yet / remove and readd Collect also not tried)
Adding the form to a device that has never had it before after making the change to the entity does get the current version of the entity lists, but then making a subsequent change to them will not be shown on device.
Syncing the device after the entity list change does however change the 'Added on' timestamp, indicating that Collect has seen a change to the entity list. Syncing with no draft change / entity change doesn't change this timestamp, as expected.
Enketo shows the latest entity state.
2. What steps can we take to reproduce this issue?
create a draft that selects from an entity list
add draft to device, view select contents
modify entity list, eg add a value / change a label
sync device, note the change in 'added on'
view select contents as unchanged.
go to project management, reconfigure, check saved/blank/cache and reset, resync draft
view select contents as unchanged.
delete draft, readd draft
view select contents as unchanged.
add draft to second device, view select and see changes to entity in select.
3. What have you tried to fix the issue?
various tests above
I have found this when testing entity based forms - it is possible to check the logic of the form, but not the function of entity behaviour (create / update). So I have resorted to using a test project and publishing the forms within that environment so they actually work as expected with entities. This is how I found out that __id (entity id) is unique to the server not the project - I was trying to duplicate my entity list into the working project after testing.
It is one of the barriers to moving to entity based work-flows that would be nice to fix - if there was a way to ‘containerise’ the draft form and entity list that might help with the adoption process - so we can test things without having long-term consequences for the server. The proposed new Entity List and Property deletion features will help with this, but it still feels a little clunky. I guess that’s the joy of working at the bleeding edge (don’t read that as a profanity!).
I hadn’t spotted that Enketo does use an updated entity (I guess it’s not cached, so when you open the draft form it loads the entity list as it last stands?)
There’s a note on Central when editing a draft form:
This Form Definition creates or updates Entities. For now, Entities are not created or updated by Draft Forms, so you will need to publish the Form to verify Entity functionality. For more information, please see this help article.
This doesn’t solve the problem, the help article gives a bit of a workaround, but it does at least alert us to the current limitations…
I know drafts don't create or update entities, in this case if i update the entity via a different method, eg a published form or direct edit in central and then sync the draft, the draft has an updated timestamp but it doesn't show the change to the entity.
@LN do you know how to resolve this without factory resetting the device or removing/reinstalling ODK or device settings: 'clear data'? that would be good, as I would have to re add every project.
I attempted removing the draft, then clearing app cache (Device Settings - apps - ODK - storage - 'Clear cache') and that didn't work.
I also switched user profiles on device (can only do this on tablet, not handset) and added the draft, it had never been added on this profile before, and it still didn't reflect the updated entity values.
Happy to dive into the file system and wipe/edit a file in the app directory if that will do it.
The issue we identified was with Central not correctly updating the fingerprint of attached lists which Collect uses to know whether an update is needed. We addressed this in Central v2025.3.0 and thought the issue was entirely fixed. I would also have expected existing drafts in Collect to "self-heal" when they got a new fingerprint and saw they had to download an update.
I know this seems really strange but it's expected. Because the list is being requested from the same URL with the same identity fingerprint, it's being retrieved from a common cache. But again, we thought this was fixed with Central v2025.3.0.
Before we go further into troubleshooting, could you please double check that your server is indeed running Central v2025.3.1 and that even when you force an update from the form list for your draft you are not seeing new Entities?
versions:
56c866fb4a995dee18bda5ce9e1a828e6863c413 (v2025.3.1)
351f3b92a9e2e2cdbd1e05f2a2137055afa3473b client (v2025.3.1)
7739129581f690a7fd51eca436d2f37bf544b7a7 server (v2025.3.0)
Well this is embarrassing... turns out that the 'updated and missing' entity item had a field used in a choice filter with a parent UUID in it that had a trailing tab (↹) after it. This wasn't caught initially as the form worked fine in Enketo with this trailing char but Collect didn't consider the string a match.
Last few characters:
before: -d1cd775bdb46
after: -d1cd775bdb46
Oh no, that's so frustrating! We'll give another round of thought to this. It's technically incorrect for Enketo to ignore whitespace there but given we can't change that without breaking existing forms maybe we just need to accept that the technically incorrect behavior is more useful to users and make it consistent across the board.