-
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
Revert 'Do not mark forms as failed to send before sending' in v2023.3 #5794
Conversation
It’s possible to edit a form that is being sent in this case. Steps to reproduce:
Usually the third form which is being sent/sending failed allows to edit after viewing it. |
Similar case: if there are some forms in "Ready to send" waiting to be send (e.g. waiting for wifi connection) when a user fills a new form and sends the forms (when wifi is on), it's possible to edit the form (forms from "Ready to send" are being sent at that moment). |
It's possible to edit form that is being sent from Bulk Finalize. Steps to reproduce:
More forms with Big images in Save as draft before bulk finalize the easier it is to reproduce |
Similar case to the previous one: Steps to reproduce:
|
It seems that only 1 form is blocked from being edited (the first one in the queque) which allows other forms to be edited after tapping "Send" while other forms are being sent e.g. in situations when sending many forms is triggered after bulk finalizing or getting wifi connection. |
Yes it always worked like that (I was explaining that during one of our meetings) I don't think we should do anything more here than bringing back what we had in previous versions (blocking the form that is being sent) |
Yes we know but the thing that worries us is that after adding another option which sends many forms (bulk finalize) the gap in preventing editing forms that are not supposed to be edited gets bigger. |
I agree that now it's easier to discover this possibility of editing forms that should be sent but still, I'm not convinced that's something we have to fix. Let's see what @seadowg and @lognaturel think. |
I'm in two minds here. The "real" fix for this will come in v2023.4 when we properly remove the ability to edit finalized forms, but the v2023.3 situation where bulk finalize and editing finalized forms are both available is pretty open to problems. I think I'd lean towards keeping the behaviour the way it is - it feels like time smoothing out the experience is wasted given that we're removing it. For the moment, we can merge this if that's the only problem and continue the discussion around if we need to make changes before releasing v2023.3. |
@grzesiek2010 @seadowg and what about our other comments about editing a form that is being sent? |
In all cases, you save and send a few forms so I believe the form you can edit is not the one that is being sent at the moment. Am I right? |
Correct |
So it seems like all those problems come down to the same root cause - only the form that is being sent is blocked, not all the others that are in the queue. |
Tested with Success! Verified on device with Android 13 Verified cases:
|
Tested with Success! Verified on device with Android 10 |
Revert 'Do not mark forms as failed to send before sending' in v2023.3
Revert 'Do not mark forms as failed to send before sending' in v2023.3
Closes #5790
Why is this the best possible solution? Were any other approaches considered?
In #5609 we removed marking forms as failed before sending them to avoid editing (this was a workaround) because we blocked editing finalized forms. Recently we have introduced the grace period and because of that wee need the workaround again.
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Please test the scenario described in the issue in the same way #5688 has been tested.
Do we need any specific form for testing your changes? If so, please attach one.
No.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew checkAll
and confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTest
locally.