You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve error message when a soft-deleted form gets re-submitted #794
In Collect go to "Ready to send- Change View- Show Sent and UnsentForms”.
Select the sent submission and tap "Send Selected”
Screenshot
Expected behavior
From the thread in collect slack- Ln :
"When re-submitting a deleted submission, here are some reasonable outcomes I can think of:
Central accepts the submission but doesn’t do anything with it (behavior when a submission isn’t deleted)
Central accepts the submission and un-deletes it
Central rejects the submission with an error saying the submission has been received and then deleted (similar to the second case but with a better error message)"
Central version shown in version.txt
https://staging.getodk.cloud/
versions: 2e5c4f7 (v2024.2.1-3-g2e5c4f7)
+4a5a9ff81efff48a1500214d9c826b590c9ddaed client (v2024.2.1-16-g4a5a9ff8)
+746ff058d32d968f13cf4e7b0a48b81f88fb21df server (v2024.2.0-79-g746ff058)
Basically, what is the behavior when you resubmit a submission that was soft-deleted for both regular submissions like in this issue and for draft submissions? I had been assuming it was simpler than the form delete case for some reason, but it's not. I'm not sure which of the three scenarios @dbemke mentioned is best
Central accepts the submission but doesn’t do anything with it (behavior when a submission isn’t deleted)
Central accepts the submission and un-deletes it
Central rejects the submission with an error saying the submission has been received and then deleted (similar to the second case but with a better error message)"
In the invisible soft-delete to be able to recover deleted draft submissions, it should probably be the second scenario where you can resubmit that submission or another submission with the same instance id and not have it complain.
Not that this was suggested, but I don't think we should allow there to be multiple submissions with the same instance ID, even if one is deleted. Otherwise, we'd have to expose the numeric submissionId for undeleting submissions, similar to how we have to expose formId for undeleting forms. That's because xmlFormId doesn't necessarily uniquely identify forms when you include deleted forms.
Central rejects the submission with an error saying the submission has been received and then deleted (similar to the second case but with a better error message)
I think this would be the easiest thing to do. I also like that it's explicit about what the situation is. Could we run with this, then see how often this situation comes up?
Could we run with this, then see how often this situation comes up?
That seems reasonable! Do you think Central should be responsible for the better error message or Collect? I can't remember, are we currently sending the error code (e.g. 409.2) in any way?
I think it would be reasonable for Central to have a special message like "This submission was previously received and deleted." If we want to be more precise, we could go with something like "The ID of this submission matches the ID of a deleted submission." but I don't think that's as helpful for users.
Alternatively, we'd want to have a special code that Collect can detect that is just about this deleted match case.
Do you think Central should be responsible for the better error message or Collect?
No strong feelings, but it kind of feels like a server concern to me. Central already returns specific Problems for uniqueness violations that we know can happen in the course of normal Central usage. For example, if you try to publish a form def with a duplicate version string, that's a specific Problem with a more informative error message (a 409.6). I think we should do something similar in this case.
are we currently sending the error code (e.g. 409.2) in any way?
I'm not 100% sure, but I don't think we send it over OpenRosa. From what I can tell, it'd be easy to do so though.
that's a specific Problem with a more informative error message (a 409.6). I think we should do something similar in this case.
Perfect, let's do that.
I don't think we send it over OpenRosa. From what I can tell, it'd be easy to do so though.
I think we should to give clients the option of having their own localized and potentially more detailed error messages. That will probably be a whole separate project, though, and we don't have to do it now.
I think we should to give clients the option of having their own localized and potentially more detailed error messages.
I personally feel like we would benefit from having server-side localization at some point. Both error messages and emails would benefit from being localized. If Backend did more localization, then Frontend would have less of that homework (#489). More to the current point, clients like Collect could tell Backend what locale they prefer for error messages via the Accept-Language header.
That will probably be a whole separate project, though, and we don't have to do it now.
Sounds good. 👍 Seeing localized error messages in the client definitely sound like a nice thing at some point.
changed the title [-]Re-submitting a submission which was deleted[/-][+]Improve error message when a soft-deleted form gets re-submitted[/+]on Nov 26, 2024
Activity
ktuite commentedon Nov 22, 2024
I'll look into this... a similar issue was coming up while i was working on #749 / getodk/central-backend#1299
Basically, what is the behavior when you resubmit a submission that was soft-deleted for both regular submissions like in this issue and for draft submissions? I had been assuming it was simpler than the form delete case for some reason, but it's not. I'm not sure which of the three scenarios @dbemke mentioned is best
In the invisible soft-delete to be able to recover deleted draft submissions, it should probably be the second scenario where you can resubmit that submission or another submission with the same instance id and not have it complain.
matthew-white commentedon Nov 22, 2024
Not that this was suggested, but I don't think we should allow there to be multiple submissions with the same instance ID, even if one is deleted. Otherwise, we'd have to expose the numeric
submissionIdfor undeleting submissions, similar to how we have to exposeformIdfor undeleting forms. That's becausexmlFormIddoesn't necessarily uniquely identify forms when you include deleted forms.I think this would be the easiest thing to do. I also like that it's explicit about what the situation is. Could we run with this, then see how often this situation comes up?
lognaturel commentedon Nov 22, 2024
That seems reasonable! Do you think Central should be responsible for the better error message or Collect? I can't remember, are we currently sending the error code (e.g. 409.2) in any way?
lognaturel commentedon Nov 22, 2024
I think it would be reasonable for Central to have a special message like "This submission was previously received and deleted." If we want to be more precise, we could go with something like "The ID of this submission matches the ID of a deleted submission." but I don't think that's as helpful for users.
Alternatively, we'd want to have a special code that Collect can detect that is just about this deleted match case.
matthew-white commentedon Nov 22, 2024
No strong feelings, but it kind of feels like a server concern to me. Central already returns specific Problems for uniqueness violations that we know can happen in the course of normal Central usage. For example, if you try to publish a form def with a duplicate version string, that's a specific Problem with a more informative error message (a 409.6). I think we should do something similar in this case.
I'm not 100% sure, but I don't think we send it over OpenRosa. From what I can tell, it'd be easy to do so though.
lognaturel commentedon Nov 22, 2024
Perfect, let's do that.
I think we should to give clients the option of having their own localized and potentially more detailed error messages. That will probably be a whole separate project, though, and we don't have to do it now.
matthew-white commentedon Nov 22, 2024
I personally feel like we would benefit from having server-side localization at some point. Both error messages and emails would benefit from being localized. If Backend did more localization, then Frontend would have less of that homework (#489). More to the current point, clients like Collect could tell Backend what locale they prefer for error messages via the
Accept-Languageheader.Sounds good. 👍 Seeing localized error messages in the client definitely sound like a nice thing at some point.
[-]Re-submitting a submission which was deleted[/-][+]Improve error message when a soft-deleted form gets re-submitted[/+]lognaturel commentedon Nov 26, 2024
Proposed error text: "This submission has been deleted. You may not resubmit it."
sadiqkhoja commentedon Dec 3, 2024
@lognaturel I am assuming this is only needed for OpenRosa endpoint, right? For REST endpoint we don't allow resubmissions.
lognaturel commentedon Dec 3, 2024
Sounds right!
srujner commentedon Dec 6, 2024
Tested with Success!