Skip to content
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

Merged
merged 11 commits into from
Mar 29, 2024

Conversation

grzesiek2010
Copy link
Member

@grzesiek2010 grzesiek2010 commented Jan 19, 2024

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 with ChangeLock 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:

  • added or modified tests for any new or changed behavior
  • run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
  • added a comment above any new strings describing it for translators
  • verified that any code or assets from external sources are properly credited in comments and/or in the about file.
  • verified that any new UI elements use theme colors. UI Components Style guidelines

@seadowg
Copy link
Member

seadowg commented Jan 26, 2024

@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!

@seadowg seadowg modified the milestones: v2024.1, v2024.2 Feb 2, 2024
@grzesiek2010 grzesiek2010 force-pushed the deleteinstances2 branch 2 times, most recently from 2ab6a59 to c277911 Compare March 22, 2024 12:11
@grzesiek2010 grzesiek2010 marked this pull request as ready for review March 22, 2024 22:40
},
foreground = {
result.value = Consumable(databaseIds.count())
changeLockProvider.getInstanceLock(projectId).withLock { acquiredLock: Boolean ->
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Member

@seadowg seadowg left a 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()
Copy link
Member

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?

Copy link
Member Author

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()
Copy link
Member

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?

Copy link
Member Author

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);
Copy link
Member

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.

Copy link
Member Author

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))
Copy link
Member

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 !!.

Copy link
Member Author

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

@seadowg seadowg merged commit 031183e into getodk:master Mar 29, 2024
6 checks passed
@dbemke
Copy link

dbemke commented Mar 29, 2024

@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?

@seadowg
Copy link
Member

seadowg commented Mar 29, 2024

@dbemke yeah that's fine!

@dbemke
Copy link

dbemke commented May 21, 2024

Tested with Success!

Verified on a device with Android 10

Verified Cases:

@srujner
Copy link

srujner commented May 21, 2024

Tested with Success!

Verified on a device with Android 13

@WKobus
Copy link

WKobus commented May 21, 2024

Tested with Success!

Verified on a device with Android 14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: done
Development

Successfully merging this pull request may close these issues.

5 participants