-
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
Block deleting saved forms if some of them are being sent #5929
Conversation
f471942
to
8d82162
Compare
@grzesiek2010 I think we should include this in v2024.1. It'd be good to prevent any weirdness that might arise from someone deleting a saved form while it's being sent. Go ahead and mark this as ready for review and request a review if you think this is good to go! |
8d82162
to
3f5cfec
Compare
2ab6a59
to
c277911
Compare
}, | ||
foreground = { | ||
result.value = Consumable(databaseIds.count()) | ||
changeLockProvider.getInstanceLock(projectId).withLock { acquiredLock: Boolean -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like this check would make more sense in InstancesDataService#deleteInstance
(maybe in a modified method that takes a list of IDs rather just one). Then, the other places that delete instances can just call that and we'll only have to handle the check in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
a21cf57
to
21d03e8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few tweaks!
|
||
update() | ||
update() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need this update
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't, good catch.
instancesRepositoryProvider.get().deleteAll() | ||
changeLockProvider.getInstanceLock(projectId).withLock { acquiredLock: Boolean -> | ||
if (acquiredLock) { | ||
instancesRepositoryProvider.get().deleteAll() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to use InstancesDataService
here instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do that. Done.
.filter(instance -> instance.getStatus().equals(Instance.STATUS_SUBMITTED)) | ||
.filter(instance -> InstanceAutoDeleteChecker.shouldInstanceBeDeleted(formsRepository, isFormAutoDeleteOptionEnabled, instance)); | ||
|
||
InstanceDeleter instanceDeleter = new InstanceDeleter(instancesRepository, formsRepository); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer the InstancesDataService
here, but I'm guessing we end up in a weird state where we've locked the ChangeLock
so can't then call deleteInstances
? If so, I guess down the line we can probably have a InstancesDataService#submitInstances
that covers submission and the clean up. That will probably make sense once we rework the upload UI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer the InstancesDataService here, but I'm guessing we end up in a weird state where we've locked the ChangeLock so can't then call deleteInstances?
Correct.
If so, I guess down the line we can probably have a InstancesDataService#submitInstances that covers submission and the clean up. That will probably make sense once we rework the upload UI.
Yeah makes sens we also need to rework the whole task since it's still android AsyncTask. Let's do that in a separate pr.
|
||
val result = viewModel.deleteForms(longArrayOf(1)) | ||
scheduler.flush() | ||
assertThat(result.value!!.value, equalTo(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use getOrAwaitValue()
here (and in the other test) instead of needing the !!
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I can but still will need !!
as the value the livedata stores is Consumable and I need to unpack it see: 85a69ba
21d03e8
to
35b597c
Compare
@grzesiek2010 @seadowg we tried testing the PR but because of the issue #6017 we're having a hard time verifying what forms and how many forms are really deleted. We would like to wait for that issue to be fixed and then test it together, cause this issue makes a half of our tests unreliable. Would it be ok to wait with testing till the fix for you, too? |
@dbemke yeah that's fine! |
Tested with Success! Verified on a device with Android 10 Verified Cases:
|
Tested with Success! Verified on a device with Android 13 |
Tested with Success! Verified on a device with Android 14 |
Why is this the best possible solution? Were any other approaches considered?
As I said in the issue I've considered adding a new status for forms that are being sent but this would require more changes and would be riskier.
ChangeLock
is something we already use in other places of the app to block accessing databases.The difference between using
ChangeLock
and introducing a new status is that with a new status, we would be able to block deleting particular forms but withChangeLock
we block deleting all existing saved forms but I think that's ok.I think this pr is enough for now because it protects users from losing data but we should consider some UI improvements to somehow let users know that sending forms is taking place in the background and deleting them is not possible. Maybe we should gray out and disable the list of saved forms (that we can use to delete them), or maybe something else. @alyblenkin COuld you think it through and file a new issue?
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?
Deleting saved forms (all of them) should be blocked when at least one of them is being sent. That means we can't delete them from the
Main menu -> Delete form
or by resetting saved forms in protected settings).It's possible that we have let's say 10 saved forms but only one of them will be sent automatically because only one has auto-send enabled on a form level. In such a case according to what I said above deleting those other 9 forms should also be blocked.
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 connectedAndroidTest
(or./gradlew testLab
) and confirmed all checks still pass