If we have a folder with downloaded files and a subfolder with more downloaded files, if we locally delete one of them and click on Available offline on the parent folder, not all the files will be set as Available offline and this is not correct.
Expected behaviour
When we click Set available offline on a folder, all its children must be set as available offline.
Steps to reproduce
If we have the following tree of files in our account:
Folder1
File1 -> downloaded
Folder2
FIle2 -> downloaded
File3 -> downloaded
We delete the file file2 locally
We go to the parent folder and set it to av.offline
We wait for the process to finish and click on Unset available offline.
We navigate to folder2 and observe that file2 has not been downloaded.
I think the problem comes from this pull request, now our code will only do a sync if the local and remote etags are different. When we click on Set available offline, the files contained within folder2 will have the same etag because they have not been modified remotely, therefore they will not be synchronized.
This bug also blocks this pull request.
Possible solution:
Create a new parameter in SynchronizeFolderUseCase called isActionSetFolderAvailableOffline set by default to false. When we perform the operation it will be set to true and a refresh of all the contents of that folder will be performed.
This issue is a regressive, so no need to add calens and release notes.
Actual behaviour
If we have a folder with downloaded files and a subfolder with more downloaded files, if we locally delete one of them and click on Available offline on the parent folder, not all the files will be set as Available offline and this is not correct.
Expected behaviour
When we click
Set available offlineon a folder, all its children must be set as available offline.Steps to reproduce
Unset available offline.I think the problem comes from this pull request, now our code will only do a sync if the local and remote etags are different. When we click on
Set available offline, the files contained within folder2 will have the same etag because they have not been modified remotely, therefore they will not be synchronized. This bug also blocks this pull request.Possible solution: Create a new parameter in
SynchronizeFolderUseCasecalledisActionSetFolderAvailableOfflineset by default to false. When we perform the operation it will be set to true and a refresh of all the contents of that folder will be performed.This issue is a regressive, so no need to add calens and release notes.