search

OpenClinica / enketo-oc

OpenClinica's fork of the Enketo web forms monorepo
Apache License 2.0
0 stars 5 forks source link

Cannot submit record in offline-capable view due to existing record error #80

Open Apotischman opened 2 years ago

Apotischman commented 2 years ago

Describe the bug When a user fills out a form with multiple Participant ID fields. the form will not allow the user to submit. The issue will occur if 1 participant ID field is filled out, or all are filled out. The error states "This record name or ID already exists."

To Reproduce Steps to reproduce the behavior. If applicable please include the smallest possible XLSForm or XForm (as zip or link).

  1. Go to an offline form with Participant ID fields
  2. Fill out at least 1 Participant ID field
  3. Click "Submit"
  4. See error

Note: The form only appears to error if there are multiple groupings in the body. I have tested just having the participant id fields being in 1 group, and another question not being in any group. This works correctly. If the question is included in a group, it fails.

Record_exists_multiple_groups.txt

Expected behavior The form should make it to the submission queue"

Screenshots Record_exists

Apotischman commented 2 years ago

This might be localized to my Chrome browser. It doesn't occur in Firefox.

Apotischman commented 2 years ago

Here is the console console_record_issue

MartijnR commented 2 years ago

http://localhost:8005/x/full/participant/4c3d9fc2bd39ce3e5e13176075e7ec29?ecid=1

See also email sent on 4/28 with subject "Multiple issues"

I've seen this issue before. I believe it doesn't have anything to do with the form definition, and it cannot be reproduced so far. Once we can reproduce it reliably, we can fix it. I may have to add the record ID to the error message as I believe that may be the only way to figure this out.

MartijnR commented 2 years ago

Happened to run across this and was able to investigate. The cause is a duplicate recordName (not instanceID). Interestingly these records were for a different form (the form had the same form title).

reproduced with http://localhost:8005/x/full/participant/9c4e3730b579618300560a13971d7f2e?ecid=1no

Screen Shot 2022-05-02 at 4 51 34 PM
MartijnR commented 2 years ago

The above means that the bug can be bypassed by:

  1. saving as draft first, and editing the record name
  2. loading the saved record and submitting it

issue reported here: https://github.com/enketo/enketo/issues/1010

Some options to resolve:

  1. add another postfix (random string 2 or 3 characters) to record name
  2. like previous but add the Enketo ID itself as the postfix or prefix (and hide it from the user in the form list?)
  3. change database schema to no longer require record name to be unique (we haven't updated a database schema before, might be complicated)
  4. like previous but roll our own uniqueness check that only looks at records under the same Enketo ID
  5. change database schema to require uniqueness of record name + enketo ID
  6. prompt users to edit the record name when this occurs
  7. Since the record name is quite irrelevant for a finalized record (since it cannot be opened), we could do one of the above prefixes and postfixes only for finalized records..
MartijnR commented 2 years ago

Looks like db.js does not support the schema changes. There is a 6 year old unreviewed PR that would add it: https://github.com/aaronpowell/db.js/pull/183. Db.js also doesn't seem to expose the native indexedDb stuff sufficiently to do this ourselves using the native API.

MartijnR commented 2 years ago

pending PR review and merge in enketo/enketo-express

MartijnR commented 2 years ago