Preventing Duplicate Entries using Dynamic Data - Does not allow 'Editing' Existing Submission

[janna]

Hi!

I have a question about dynamic data attachments, relating to preventing a duplicate entry for an ID code - but unique behaviour that then prevents any sort of editing of data after the initial submission.

Here is my XLSForm for my test use-case:
a6TsoUEr7MieHBYT7tzef4.xlsx (9.6 KB)

What I am doing is linking the form to itself - it is both the parent and the child.

1. When I put in a new HH ID number, the form counts the number of times that HH ID has previously been entered in the data table.

2. If the HH ID has not been previously used (e.g., ${hhid_check} = 0) - then the form will validate and you can submit the new data.
   

   

3. However, if the HH ID has been previously used (e.g., ${hhid_check} > 0) - then the form shows an ‘error note’ and will not allow the form to be submitted. It requires a correction of the HH ID entered.
   

   

Overall, this method prevents duplication of HH ID numbers being submitted.

However, here’s the problem:
In my workflow, I have a step where data cleaning/correction will happen from KoboToolbox. But when going to ‘editing’ mode of the form - I cannot edit the form because of the dynamic data attachment.

1. So in the data table, you can see that there is only one row with HHID LHS.BF.0SK.002:
   

   

2. Now I want to edit that submission to change the number of HH members from 5 to 6, for example if I made an error in my submission. But when I click to edit the submission, change to 6, and then submit again - the error message appears that there is a previous submission of this HH ID number. So I cannot submit the edit.
   

   

Essentially, this error prevents any data cleaning of a form where I use dynamic data attachments to prevent duplication of an ID number.

Is there a workaround?

As I’m brainstorming a solution, I wonder if this is somewhat a flaw in how the parent/child relationship executes when in editing mode…as in, I think it’s doing exactly as it’s programmed to do…but there is a difference in deduplicating for a new submission and then editing an existing submission.

You wouldn’t want to be able to change a HH ID when in editing mode to an ID number that has already been used, but likewise, shouldn’t you be able to not change the ID number when editing other fields, and still be allowed to submit the edit?

With this behaviour, data cleaning/editing within KoboToolbox is impossible.

If someone has come across this problem before and has figured out a workaround, please let me know! Or if this is a known limitation of dynamic data attachments, it would also be helpful to understand.

Many thanks in advance!
Janna

[Kal_Lam]

@janna, yes the DDA feature would not allow you to edit your submission (from the server) if the identifier variable has already used that certain value. However, maybe you could use this approach to capture that identifier variable (recorded earlier) by following this post and storing it under the hidden variable:

After completing a survey the score should display in the screen and once it's displayed the responses should not be editable. How can this be done?

@yasirsaeeed, you could do this by using the once() function as shown in the image below: survey sheet as seen in your XLSForm: [image] But please note that this approach could make your survey long as you will need to make a hidden copy of all your questions and use the once() function under the calculation header. So with this approach, the first input made to the question will be stored in the hidden question type which will remain the same even if you edit your submission from the server…

You could then change that identifier variable value to something else when editing your submission so that the server would get a new value for the same and would not take the previous value to block your changes.

So the approach would be as follows:

1. You store your ID as LHS.BF.OSK.002
2. Try to edit your submission on the server (you are not allowed)
3. Make necessary changes to your form and also change the ID from LHS.BF.OSK.002 to LHS.BF.OSK.002.1 or something that marks the change.
4. Your submission is now unique and will be submitted to the server.

If you wish to see the original ID for any submissions that were edited, you could check the hidden variable value where we used the once() function to capture the original value entered which would be LHS.BF.OSK.002 in your case even through you have later changed it to LHS.BF.OSK.002.1 or whatsoever.

Hope this workaround works for you. But at the same time, let us also see if the community has some other easier workaround for you.

[janna]

@Kal_Lam this is an interesting workaround, thank you for the idea.