-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collect URL-encodes form id for encrypted forms #6492
Comments
@lognaturel Would like to pick this up. I guess we will need to stop the unicode parsing of the ID when the form is stored? |
Thanks, @karntrehan! This one is not urgent so it should be a good one to look at. I don't think the problem is with the form definition because this works fine with non-encrypted forms. My guess is that the code path that writes the submission is different for encrypted and non-encrypted forms and that the encrypted one doesn't do encoding the same way. As far as I know, the code for building encrypted submissions hasn't been touched in many years. |
This is helpful. Let me dig into this today. :) |
I guess this is the code: collect/collect_app/src/main/java/org/odk/collect/android/utilities/EncryptionUtils.java Line 507 in 90d41ae
Looking deeper. |
Hie @yanokwa,
If someone could upload this form to the demo server, I could check the submission flow as well. |
The encoding issue is in the submission. You can verify this either by debugging and looking at the submission contents (maybe start with the line you pointed out) or by finalizing the submission and then looking at it on the device using
Then go to your project (probably |
If a form id contains Unicode characters (e.g., ã, ß, 箸) and the form is encrypted, the submission for that form will have a URL-encrypted id.
For example, my-båd-førm.xlsx has a form ID of
my-båd-førm
in Central's DB while Collect's XML shows it asmy-båd-førm
. Upon submission, Collect says "Could not find the resource you were looking for" (response from Central because the formid isn't found).That form ID works as expected with non-encrypted forms.
The text was updated successfully, but these errors were encountered: