Comment 1 for bug 1437641

Revision history for this message
Stefano Verzegnassi (verzegnassi-stefano) wrote :

I consider this as a "Won't fix" issue.
Document Viewer is not really intended to open something different from documents, and there may be some "limitation" (actually they are security features) in the platform itself if I go for implementing it.

Let me explain it better.
The current application model provides isolation between applications. That means that while importing a document (or any other file) from another application, the file is copied in another path, in order to avoid that some malware can edit files and/or access to sensible user's data.

Since you need just to view some file (and not to edit them), you actually don't need to view the original files.
There's anyway an issue here: a copy is created in HOME/Documents, and you need to manually delete it.
We can not workaround it, unless we implement a full-featured file manager in the app (and we'd need to support PAM autentication and other security stuff - breaking a lot the UX), but this won't fit with our plans for the project.
Any file imported through Content Hub is copied in a "trusted" folder, then imported in the app. No exceptions.

However there's an app that can access to the whole file system: the file manager.
Moreover, usually file managers also provide a basic text editor for such scenarios (e.g. ES File Manager on Android platform).

Being the docviewer just a document viewer, and the file manager a tool for advanced usage/user, this is a useful feature that filemanager-app could provide.

I'll mark filemanager-app as affected by this bug, and update the status as "Incomplete" for docviewer-app, since it needs more discussions with filemanager devs.

@File Manager devs:
I know you guys may not have time for implement this, but it may be worth to discuss about this issue.
I'm open to any discussion and/or collaboration for fixing this.