[FEATURE REQUEST] User defined delayed removal of images after auto-upload.

[tekchip]

Is your feature request related to a problem? Please describe. The issue with "original file will be: removed from original folder" being immediate means that a new photo can't readily or easily be shared through third party apps because it's no longer local to the phone. Sharing to, for example, Instagram becomes much more difficult if not impossible for less tech savvy users.

Describe the solution you'd like All images should be backed up immediately, but the removal from the device should be able to be delayed so that photos stay local for some arbitrary period of time to allow for use in other apps. This can be accomplished by a timing setting in the "original file will be" dialogue that lets the user set an arbitrary amount of time before photos are removed from the device. In other apps that sync with servers this is usually accomplished with a field for the user to set a number and a drop down to define the increment of time expressed in hours, days, weeks, months, or years(!?). See mockup below.

Describe alternatives you've considered I'm not sure there are any.

Additional context

TASKS

• [ ] Research (if needed)
• [ ] Create branch feature/feature_name
• [ ] Development tasks
  • [ ] Implement whatever
  • [ ] ...
  • [ ] Implement unit tests (if needed)
• [ ] Code review and apply changes requested
• [ ] Design test plan
• [ ] QA
• [ ] Merge branch feature/feature_name into master

[JuancaG05]

Hi @tekchip! Thanks for opening a new issue! 😸

Not sure about the feature you are requesting... This can be achieved by just keeping the original file in the folder and then being removed manually by the user whenever they want. I don't know if an arbitrary time to delete it after the backup is suitable, it could lead to many problems: what if the file was already removed (or moved to another folder) before the specified time?

We'll discuss with the team anyway. You mentioned that other sync apps have this feature, would you mind to post a couple of example screenshots so that we can see similar behaviours and whether it is feasible? Thanks in advance 🤠

[tekchip]

This can be achieved by just keeping the original file in the folder and then being removed manually by the user whenever they want.

See this is exactly where the problem lies. Many users now, often younger, expect everything to be automagical and don't perceive a problem, like low disk space, until it's full and becomes a problem. By then it's a monumental task, especially to less savvy users, to figure out what stays and what goes in a sea of potentially thousands of photos or videos. It's also a pain for those more experienced to help them when this happens. I have children. I've been here many times already.

You've created a feature that accomplishes a backup, sure, but stopped at freeing space which is at a premium for most mobile users. It also effectively breaks mobile device functionality in that photos can't be shared because the recent photo is gone from the device.

Perhaps I should frame this like a bug instead:

[BUG] "original file will be: removed from original folder" breaks the ability for the user to upload images to other applications on their device if not done immediately.

[EXPECTED BEHAVIOR] The user can control how long photos are available to them on the local device so they have recent photos available to share in other apps.

Remediation of "problems"

...it could lead to many problems: what if the file was already removed (or moved to another folder) before the specified time?

You seem to be implying I'm asking for auto-upload to sync in both directions. I'm not. That would cause inconsistency or conflicts. Currently auto-sync is one way, upload. So if there are inconsistency between the device and server then something has gone horribly wrong in your one directional upload.

Currently what happens if a user deletes a photo in between taking it and the next auto-upload? Nothing, correct?

On the server side once a photo is already uploaded and the user wants it gone they'd have to manage their owncloud files which is not dissimilar from what you implied about them just managing files on their device, only now that management is shifted to the server where an admin or server owner can aid them more easily if they need it.

...would you mind to post a couple of example screenshots so that we can see similar behaviours and whether it is feasible?

Not the best example as joplin sync is bi-directional.

I don't have a lot of examples because frustratingly few pieces of software have bothered to institute such features. I've filed similar feature requests with many projects/products already. The most obviously similar one is Joplin Notes that syncs notes to webdav. https://joplinapp.org/ If there is a conflict found between on device and on server it pops up a warning and prompts the user to resolve the conflict.

Here is Joplins update interface showing their timed sync feature.

Their conflicts resolution interface is basically a tab that displays which content conflicts and then has some buttons that allows you to decide what to do with it. Discard, local. Discard, server. etc.

Their FAQ/Wiki entry on the subject. https://joplinapp.org/help/apps/conflict/

EDIT: Edited greatly for clarity. Sorry about that.

[JuancaG05]

Hi @tekchip, thanks for the examples, but I think in this case conflicts have nothing to do (we do have conflicts management in the ownCloud app as well), and the first screenshot you show refers to Synchronization interval, which is not directly related to the feature you are asking for (delay in removal) either.

I think if this feature doesn't exist yet in any other similar app is because it's for a very very specific use case, but doesn't apply to a general use. Too much complexity for a very specific (and would have to see how much used) feature. In any case, we can consider this issue for our roadmap in a future, we'll prioritize 👍.

[tekchip]

So you're saying you won't consider the feature because I can't show some other app doesn't use identical terminology?

While joplin does "synchronize" bi-directional the concept is effectively the same. Only owncloud's auto-upload doesn't, shouldn't, result in conflict because it happens to be unidirectional.

A feature that prevents breaking of the ability of users to upload to apps on their device doesn't sound like a general use case? Who wouldn't that benefit?

There is virtually no added complexity beyond trying to get you to understand this request.

Files continue to upload on the standard interval.

The user simply identifies when they get removed from the device.

If, later, the user or admin of the files wants them gone from the owncloud server, the device with larger storage and the support of the more tech savvy admin, then they can be removed/managed there.

[jesmrec]

Let's take a look to the new expected behaviour:

[EXPECTED BEHAVIOR] The user can control how long photos are available to them on the local device so they have recent photos available to share in other apps.

ownCloud is related with files in devices, for sure. But, the target is syncing files against a known backend under your control. Local files management is out of our scope beyond getting them to push to the server. The suggested feature would open a huge casuistic in which we involve processes running in the app working against files stored in the device. That comes to a first problem: permissions. Technically feasible, but not desirable (we got rid of such permission not long ago). Believe me, destructive actions can lead to more confusion to "not savvy" users.

On the other hand, we try to make the live easier to the users but we can not control their lives (better to say, their devices). They should check how much free / non-free space is there in their devices. In case they'd flood the device with media files, ownCloud app is not the responsible to free, after those files are pushed and removed in the auto uploads. Please, try to understand us, this is out from our focus.

The suggested use case is anyway feasible with the current alternatives:

• Keep the local files that are able to be shared with other apps
• Remove the local files, and after being uploaded to the server, share them from the mobile app that supports sharing with 3rd party apps.

Finally, i agree that a bi-directional sync is cool, also for files that do not come from camera. That is a feature request in our heads (let's see in which sync conditions). But "delayed removal of files in local storage from app" does sound out of scope. I understand the use case you explained and makes totally sense, but the way to fix it has more cons than pros.

Let's keep this one opened in case more users and friends from community wants to share their thoughts.

[tekchip]

Local files management is out of our scope beyond getting them to push to the server.

Really? Because the feature in question is called:

"original file will be: removed from original folder"

That sounds like you're managing some files to me.

That comes to a first problem: permissions. Technically feasible, but not desirable (we got rid of such permission not long ago).

That's odd I just installed the app to test all this before I filed this request. Each time I choose the folder I want the files removed from via "original file will be: removed from original folder" it prompted me to grant the owncloud app permissions so it can remove these files.

On the other hand, we try to make the live easier to the users...

This doesn't seem to be true. I'm a user who's made a request that would make it feasible for my children, and less tech savvy family, to be able to utilize ownCloud in a way that would remove the burden of having to help them clear space on their mobile devices when they get full. It would also allow them to continue to use their photo sharing apps as usual instead of having to filter through the owncloud app. But you seem to have no desire to do this.

In case they'd flood the device with media files, ownCloud app is not the responsible to free, after those files are pushed and removed in the auto uploads.

That's literally what your existing feature "original file will be: removed from original folder" does! You're saying you're both responsible and not responsible in the same sentence!?

Remove the local files, and after being uploaded to the server, share them from the mobile app that supports sharing with 3rd party apps.

Once again you're missing the point. Non-tech savvy users don't know to go to the ownCloud app to share files to Instagram, or Facebook or whatever. They go to those apps and expect to find their photos to share from within those apps. The feature I've requested resolves both the issue of them being able to do that AND also achieves the goal of the pre-existing "original file will be: removed from original folder".

Perhaps you should have someone else review this request and try to explain to you the problem, and the solution I've presented, because I'm clearly not able to convey it to you.

[JuancaG05]

As we already stated twice, in opposite to what you say, we'll keep the issue open:

In any case, we can consider this issue for our roadmap in a future, we'll prioritize 👍.

Let's keep this one opened in case more users and friends from community wants to share their thoughts.

We're just trying to understand the request and see its value. What you cannot demand is prioritizing your request against many others we have. In any case, we're an open-source project, if you think this has a great value and that it's not that complex, you can always send a PR from your own and we'll be happy to review it 🙂.

No more discussion needed here at the moment.