1. What is the issue? Please be detailed.
I have been testing new forms on a device and found a tricky problem...
I completed a form on the device with a DRAFT project but it was temporarily not connected to the internet so there is one submission that remains in 'Ready to Send'. I made an edit to the form definition and published it (it's within a Test project so that I could test the related entity updates).
When I tried to delete the DRAFT project on the device I was unable as there are unsent forms... But it cannot send the form as the DRAFT form definition / project is no longer available on Central. I am stuck in a 'doom loop' - there is no obvious way to delete that submission and without doing so I cannot delete the Project.
2. What steps can we take to reproduce this issue?
As above:
Create a draft form and test on device.
Disconnect device from the internet and complete a form. Do not allow it to send
Publish or abandon draft on Central.
Try to delete the DRAFT project on the device.
3. What have you tried to fix the issue?
Delete forms - the Ready to Send form is not on the list, only the test submissions that were sent.
Reset the configuration for that project - shows success on all categories, but the draft (ready to send) form remains.
MANUALLY deleting the 'metadata' folder on the device: Android/data/org.odk.collect.android/files/projects/[projectuuid]/metadata - this works (I tried this as I was writing this post!)
So, it looks like this is a way to handle an unusual scenario, but it would perhaps be more intuitive for the 'reset' function to work as a means of deleting (resetting) 'Saved forms' as it appears to indicate on the device... Or to be able to delete 'Ready to Send' forms manually [I can see why you might not want that function to be too easily available to prevent data loss when working offline!]. But having to explore the 'Here be dragons' folders on the device is not ideal.
It makes sense that you shouldn't easily be able to delete a published project with unsent forms, but to me it also makes sense that deleting a draft form (are these considered projects as a draft is always one qr, one form, but an app user qr results in one qr, one to many forms...?) could be more permissive and allow deleting the draft even with unsents, as these are only for testing and will be destroyed by central upon next draft or publishing. This assumes collect can tell the difference and apply different rules.
Thanks for this feedback—we’re going to discuss it as a team. We want to strike a balance between preventing unintentional data loss and avoiding a ‘doom loop’, especially when working on test projects. I think there might be an alternative solution that doesn't completely block people.
Hi @seewhy! What if we had a dialog prompting the user to type in the word 'Delete' to confirm they want to delete the project? We think this might be just enough friction to get the user to pause and make sure that deleting the project is their intent!
Still working on the text, but here is a mockup to give you an idea. Curious to hear from folks!
Assuming that ODK Collect has no way of differentiating between DRAFT 'projects' (i.e. the testing phase) and 'real' projects.
This method really makes you need to WANT to delete a project, but is still simple enough. Assuming people read the instructions - you could always flash the 'type delete to confirm this action' if someone tries to delete without typing, or maybe the button is (already) inactive until the word is typed?
I would make it case insensitive, just to avoid annoyance - if someone has got that far it would feel a bit pedantic to case-check them
Although it might complicate matters, is there a way of adding a summary of what still exists in the 'project' when someone tries to delete it - this would be a good cross check (if there are multiple forms for example, it would be obvious is wasn't a DRAFT project):
3 Form definitions
27 Sent forms
5 Draft forms
Thanks for your quick response! Yes, the button is inactive until the word is typed. I also had another iteration where we didn't require the user to type anything, and in that case the CTA is active when you land on the dialog, which doesn't seem to have enough friction and could easily lead to a mistake.
And I agree with making it case insensitive to avoid any faff.
I think that should be possible! I'll double check with the team, but I think that's a great idea.
Great, thanks. I like a bit of friction when the stakes are high.
You could always use the 'check box' to confirm... 'I realise that I'm about to do something terminally stupid if this project has data' or a more helpful and encouraging phraseology...
We will keep you posted!
