[FEATURE REQUEST] allow targeting directories in SAF

[theScrabi]

Is your feature request related to a problem? Please describe.
It would be a useful enhancement if other apps could push files to the ownCloud app without the user having to actively intervene. This could be an app that uses ownCloud as a storage backend for backing up user settings, or an app that uses ownCloud as a work directory.

Additional context
In this screencast you can see that I am capable of accessing onwCloud normally when using the Android files app. However when I want to set a target directory for OandBackupX you can see it is not visible as possible provider.

clip.mp4

TASKS

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

PR

• App

[abelgardep]

This feature means ownCloud to be visible when an app asks forACTION_OPEN_DOCUMENT_TREE and it gives the other app persistent access to the entire directory. At the moment we use this when asking the user to select the camera folder

I think that giving persistent access to an ownCloud directory could lead to security problems. Furthermore, this article states that it should not rely on network access:

Ideally, this request shouldn’t rely on the network as it can be called frequently and in rapid succession so if you want to support this use case, make sure you can handle this request locally.

So, I think that a way to accomplish this, would be that external apps perform a backup, store it somewhere in the local storage, and then ownCloud will upload the files to the server in a secure way. It would be pretty similar to current camera uploads but for any file format, not only images and videos.

[azukaar]

Being able to do backups is just a single use case, but for example, if you need to set a folder for INPUT rather than OUTPUT from owncloud (ex: I want to scan the book folder that is inside owncloud from a book app) then since scoped storage prevent a direct link to be created to the already synced files, not being able to set a folder completely wall off the data other app despite of what the user is trying to do

[hannesa2]

This feature means ownCloud to be visible when an app asks forACTION_OPEN_DOCUMENT_TREE and it gives the other app persistent access to the entire directory. ...

I think that giving persistent access to an ownCloud directory could lead to security problems

@abelgardep
Yeah, this is what I exactly need ! when I don't concern about security and want to use my own build app, what has to be done, to make it work ?

Btw, I played around to make it work, but this

causes just a

Unable to get provider androidx.core.content.FileProvider: java.lang.SecurityException: Provider must not be exported

I've no clue how to fix it and this security-thingy is just a pain in the a.. I don't need it

[hannesa2]

@abelgardep A lot of guys want access to there own files and want a open solution !
If you don't want to make ownCloud open, I at least want to make it open on my own fork.

Please give me a hint how to make ownCloud open, probably configurable ?

[abelgardep]

@abelgardep A lot of guys want access to there own files and want a open solution ! If you don't want to make ownCloud open, I at least want to make it open on my own fork.

Please give me a hint how to make ownCloud open, probably configurable ?

Hello @hannesa2, on the other issue I pointed you to read a little article about the DocumentsProvider, so you could gather information about it and know its restrictions.

ACTION_OPEN_DOCUMENT_TREE
While ACTION_GET_CONTENT and ACTION_OPEN_DOCUMENT focus on providing access to one or more individual documents, ACTION_OPEN_DOCUMENT_TREE was added in API 21 to allow a user to select an entire directory, giving the other app persistent access to the entire directory.

Supporting ACTION_OPEN_DOCUMENT_TREE involves adding FLAG_SUPPORTS_IS_CHILD to your root and implementing isChildDocument(). This allows the framework to confirm that the given document ID is part of a certain document tree: remember a document can be in multiple places in your hierarchy so this is checking ‘downward’ as it were from parent to potential descendant (child, grandchild, etc).

Ideally, this request shouldn’t rely on the network as it can be called frequently and in rapid succession so if you want to support this use case, make sure you can handle this request locally.

This is from the article I recommended you reading here

Try adding the FLAG_SUPPORT_IS_CHILD to the RootCursor and implement isChildDocument() on the DocumentsStorageProvider

Let me know if you need something else 🍻

[hannesa2]

@abelgardep Yes ! With your help, I can open tree from other app 👍

When I select directory, I can access content 👍

DocumentFile.fromTreeUri(application, data)
            childDocuments = documentsTree?.listFiles()?.toCachingList()
               //  ?.filter { it.type == "application/dicom" } <-- type is always null
                ?.sortedBy {
                    it.name
                }

A: but when I try to open it val stream = contentResolver?.openInputStream(uri) I run into a securityException
B: type is always null, so I can't filter on it

Do you know what's wrong here ?

Maybe it's somehow off topic, but I guess there are several guy, who are interested in.