owncloud/web

:dragon_face: Next generation frontend for ownCloud Infinite Scale

ownCloud Web

With ownCloud Web you can manage your ownCloud in your browser.

ownCloud Web is a single page, standalone frontend, based on modern web technologies. It brings new features as well as improved user flows and can be deployed independent of the backend server.

Compatiblity

Usage of Web UI and ownCloud 10 as backend is not recommended starting with version 7.1.0 of the Web UI, meaning newer versions only support ownCloud Infinite Scale. If you want to use the Web UI with ownCloud 10, please use App version 7.0.2. Critical bugs can be fixed upon request.

Examples

Here are some examples of what you can do with ownCloud Web:

• 🗂 Files: Upload, download, search and manage files (as you may know it for example from Dropbox, OneDrive, Google Drive etc.).
• 👥 Share: Allow fine-grained access to files and whole folders directly with other users on your ownCloud.
• 🔗 Links: Create links and share them with anyone in the world - optional password-protection available.
• 📝 Write: Edit your documents with the editor of your choice like ONLYOFFICE, Collabora or Microsoft Word and more.
• 🤝 Collaborate in real-time on documents.
• 🚀 Spaces: You have to manage important projects? Let Spaces, the new special folders, keep order.
• ◀️ Versioning Saved the wrong version? We have the time machine you were looking for! Easily go back in time and restore older versions of your files.
• 📥 Drop-folders: Collect files from other people in one folder via a simple link, ex. homework from pupils or photos from your family - optional password-protection available.
• 🔒 Privacy first: ownCloud Web is GDPR compliant and can both be used completely internally or together with external people. It also will never "phone home".
• 🛡 Secure: ownCloud Web is an open source project which means that you can track every action, update and dependency of the software.
• ♿ Inclusive: Our goal is to be accessible for kids as well as seniors and for newbies as well as experts - since we are all affected by physical and cognitive limitations, depending on our personal situation.
• 🧩 Extensible: ownCloud Web is build as a plattform that can be extended in the most developer friendly way.
• 🌗 Darkmode: Initialized with your browser settings, and easily switched to please your eyes better.
• 🎭 Themes: Customize to your branding needs or personal taste in no time.
• 👉 and many more...

While the web frontend provides a performant, elegant, accessible and themeable base, it also aims to be extendable with custom extensions provided by external developers.

Live Demos

• Infinitescale - Try the latest commit on the master branch with an ownCloud Infinite Scale backend:

  • Demo: https://ocis.ocis-web.latest.owncloud.works
  • User: einstein
  • Password: relativity

• Server - Try version 6.0.0 of web with an ownCloud Server backend:

  • Demo: https://web.owncloud.com/
  • User: demo
  • Password: demo

Repository structure

The backbone of this project is built by the following parts of the packages:

• client: Generated TypeScript client for communications with the ownCloud Infinite Scale graph API
• container: Static assets and rarely changing base files
• pkg: Shared logic for various places inside the codebase
• runtime: Central place of (user) authentication, provisioning of the user interface layout, client side storage, routing, theming, dependencies and (sub)application handling

The repository's packages also contains the following apps, which can be en-/disabled via the config.json:

• draw-io: An extension for creating, opening and editing .draw files
• external: An extension for creating, opening and editing files using the WOPI server
• files: The default extension and core part of the project, responsible for file sync-and-share - up- and downloading, sharing with other users/groups or via links, version management and more
• pdf-viewer: An extension for opening PDF files without leaving the UI
• preview: An extension for opening audio, video and image files
• search: An extension for registering search providers, which then get rendered into the layout in the runtime using a portal
• text-editor: An extension for creating, opening and editing plain text files, like e.g. .md or .txt
• user-management: An extension for basic user and group management by the admin. Only works with the Infinite Scale platform, as it uses the graph API.

Releases

We currently publish a new release every couple of weeks, strictly following semver. Releases and their corresponding changelogs can be found on the release page on GitHub.

Documentation

The documentation is an important part of this project and can be found on owncloud.dev. If you want to contribute to the documentation you can find the source files in the docs folder of this repository.

Contribution

Contribution in the form of bug reports, user feedback or actual code is always welcome! We do have a contribution guide, actively use the good-first-issue label and try to feedback on issues and pull requests in a timely manner. There is also a setup guide for building and running web locally.

Tests

We assert the quality of this project by running an automated CI, while a guide on running the tests locally can be found in the testing documentation.

Jobs

At ownCloud, we are always looking for new additions to our team. You are welcome to take a look at our open positions.

License

GNU Affero General Public License - Details

web's Issues

js-owncloud-client as vue.js plugin

Create a js-owncloud-client vue.js plugin for ease of use in Phoenix and other future ownCloud Apps.

Allow apps to register to a connected event ....

An app wants to start with processing as soon as phoenix is connected to the server.
We might want to add a mixin which allows us to perform actions as soon as the connection is established.

To take care of: how will this work in offline mode?

Replace axios with vue-resource

Let's consider using vue-resource instead of axios.
We could expose this via the basic OC.Vue instance for all to use.

Don't load anything from the Internet

We should bundle everything:

• material icons, etc

Currently it connects to remote sites like google for downloading these.

@felixheidecke

Themability ...

We need a mechanism which allow to theme the front end.

There might be a build step required to create a theme/branding for it.

Elements which need to be themable:

• colors of text and background
• logo on login screen (if we will have one)
• logo on top bar
• logo on public share pages
• product name: ownCloud -> awesomeCloud
• product slogan
• mime icons

Requirement for the theme:

• isolated file to be loaded via the config
• no recompilation of any app or the phoenix skeleton
• themes shall apply to all apps and plugins

File List feature

Ticket to track requirements and progress on the file list feature.
A task is done when the file list was wired up already to the APIs (no dummy)

• list files
• file actions: see #149
• delete single file
• delete multiple files
• select/deselct multiple files for bulk actions
• select/deselct all files for bulk actions
• rename single file
• create new folder
• create new file (TODO: ticket for extensibility of file formats like text editor, etc, like NewFileMenu in core) #274
• move selected entries to subfolder with drag and drop
• drag to breadcrumb to move to parent folder
• breadcrumbs
• file download
• file upload (with and without chunking) #67
• progress bar for operations #275
• spinners / state for all operations #275
• sidebar (to be tracked in detail in a separate ticket)

@OshanIvantha @felixheidecke please update accordingly and link to tickets and PRs

Phoenix 0.1.0 Release

I suggest to aim for the following goals to be able to have a first beta release of the Phoenix project:

• organize the code in a way that makes it packagable as a marketplace app: #40
• one vue to rule them all #146
• Separate phoenix scaffold from files_app #55
• individual components/apps must be packageable as well, for example:
  • files app ?
  • file list: #150
  • sharing frontend (sidebar): #37
• build scripts for release
• baseline for JS unit test / acceptance tests

@DeepDiver1975 @felixheidecke @pmaier1 @patrickjahns

Input for sharing tab

I want to collect/reference input for the sharing tab in here.

folder to small

Hola chicos,

I learned about this design from the blog. I find it nice, but I instantly saw some things I'd like to be better. I found that the file icons are just to small compared to the rest of the UI elements. Example:

You can see that the file icons are even a bit smaller than the checkbox beside it. I don't like it, because the meaning of the icon is harder to detect, and ... it just does not look right.

Actually the size of the icons as they are right now is pretty good I think:

Accessibility - support screenreaders and so on

refs owncloud/core#25466

this is only a placeholder as of now - needs detailed requirements and specification

Please help me,how to solve the problem: Please provide a valid owncloud instance

I have installed owncloud in virtual machine, The content named config.php is the following:
[root@localhost config]# cat config.php
<?php $CONFIG = array ( 'instanceid' => 'oc5pxm45zzcq', 'passwordsalt' => 'U724aD7L/QNWvyuPrUo6v6FoMI5Cto', 'secret' => 'hK5Y3jH/5wpYt/bKcVlX9oOAMV/fN6dLW5oAfcVX/qCzdHD/', 'trusted_domains' => )

In client, I modified the file named config.json like this:
{ "servers" : [ "http://192.168.201.201/owncloud" ], "theme": "owncloud", "version": "10.0.8", "instanceid": "oc5pxm45zzcq", "apps" : [ { "id" : "files" } ] }
when I call login function to login, I got a error: Please provide a valid owncloud instance.
where should I get instanceid from ?
Could anyone please help me to solve the issue?

Sharing sidebar app

The sharing sidebar mock up of Phoenix must be moved to a new app based on webpack + vue JS + UI Kit, with everything that we usually need for a marketplace app (Makefile, etc).

The app in question will only contain frontend parts, with additional boilerplate to make sure said frontend still works with ownCloud 10.0.x and can register its panel into the files app sidebar.

Use the js-owncloud-client lib to connect ...

https://github.com/noveens/js-owncloud-client

This library allows pure js access to any owncloud instance. CORS is supported in owncloud server since 10.0.4

[REQ] ignore *.bundles.js files and /apps/* in subfolder

Who is able to rewrite history and remove already pushed bundle files?
Apps in the respective need a special treatment as mentioned in #55

Versions tab

Story:

Given a user is logged in
When the user selects details view of a file
Then a version tab shall exist on the details view

When the user selects the version tab
Then all version of the file shall be displayed holding the information: File size, Save time, File icon (or review if available) and the file actions: download and restore (UX to be defined)

When the user chooses the action download on a version
Then this version shall be downloaded

When the user chooses the restore action
Then this version will be used as current version

Tasks:

• Implement the necessary UI components (2MD)
• Integrate with existing webdav api in js-owncloud-client owncloud/owncloud-sdk#93 (3MD)

New app: gallery

ToDo - collect requirements

Separate phoenix scaffold from files_app

All apps in /apps (especially the files app) should be moved to a separate repo.
Scaffolding in the base folder and core will have a separate Makefile and js dependencies.

@PVince81 apparently doesn't like git submodules, but I suggest adding the shipped apps as submodules in die apps folder. Good or stupid idea?

@DeepDiver1975, @patrickjahns thoughts?

GSOC Milestone Tracking

Milestones for the Petabyte-Scale Cloud Storage File Manager GSOC project

M1. Community Bonding

• M1.1 Get to know the community better
• M1.2 Learn about the CERN, ownCloud and AARNet organizations
• M1.3 Learn about the tools that will be used
• M1.4 Get familiar with Phoenix

M2. Implement the Files and Sharing functionalities

Evaluation: 11th June

• M2.1 Implement file browsing
• M2.2 Implement data upload and data download
• M2.3 Implement the public link functionality
• M2.4 Implement the sharing functionality
• M2.5 Perform test of various corner cases than can arise
• M2.6 Ensure proper documentation of the written code

URL Separation (of concerns)

Proposal

"We" need to fetch information from the URL in order to load phoenix config files, apps as well as allow apps themselves to use routers. This the idea is to separate the URL @ the # value, the later is for apps to use, the rest determines current app and path.

Parsing from right to left:

https://my.cool.server.com/cloud/v11/awesome_app/#listby/awesomeness
|--------------- BASE --------------|--- APP ---|- not our concern -|

Replace uikit submodule with npm package

Any reason we need the UIKit submodule ?

It takes ages to clone. Wouldn't it be simpler to add uikit through npm and then adjust the makefile to make it compile from there ?

@felixheidecke

[Placeholder] Branding Support

An important feature for ownCloud clients is the ability to brand them. Phoenix should be built with a list of branding items in mind.

e.g. https://github.com/owncloud/core/blob/master/apps/theme-example/defaults.php should be a good place to start the recollection of those.

Authentication layer

Before accessing any APIs we'll need a way for all frontend code to ensure that the user is authenticated first.

• login page / dialog (ideally that can work not only with password but also totp, oauth, etc)
• some middleware that can catch auth errors on ajax calls and redirect to login flow

@DeepDiver1975 @SamuAlfageme @felixheidecke

Accessibility

We need to keep a close eye on accessibility.

• research on tools

• research on test metrics

• research on validators

• research on vue specific support

• vuejs/v2.vuejs.org#1002

• https://medium.com/@emilymears/getting-started-with-web-accessibility-in-vue-17e2c4ea0842

Acceptance tests

@felixboehm :

We want to have acceptance testing for phoenix (from day one)

Here a short comparison of the proposed tools that does not claim to be complete, please add your points

Tools

Cypress https://www.cypress.io/

+ easy to install
+ good debugging
+ has a lot of knowledge about what's going on in the app/browser (more than selenium). e.g. can send raw requests, has spies, stubs etc.
+ cucumber plugin https://github.com/TheBrainFamily/cypress-cucumber-preprocessor
- supports only Chrome* browsers https://docs.cypress.io/guides/guides/launching-browsers.html#Browsers
- each test is limited to only visiting a single superdomain https://docs.cypress.io/guides/references/trade-offs.html#Same-origin (currently we are using multiple super-domains for fed. sharing. We might get around it by using multiple sub-domains)
- further trade-offs https://docs.cypress.io/guides/references/trade-offs.html
? runs inside of the browser/does not use selenium (not sure if that i good or bad, a little bit of discussion here https://www.joecolantonio.com/2017/11/16/cypress-io-vs-selenium-test-automation/)
? don't really uses page objects the way we do now (that does not need to be bad, but a bit of a different approach) https://docs.cypress.io/faq/questions/using-cypress-faq.html#Can-I-use-the-Page-Object-pattern

TestCafe https://devexpress.github.io/testcafe/

+ easy to install
+ test debugger https://testcafe.devexpress.com/Documentation/Using_TestCafe/Test_Debugging/
+ Implicit auto-waits mechanism. TestCafe automatically waits for XHR requests and page loads, so you don’t need to take care of it in your code. 🕺 👍 🎉 But I wonder how good that works in practice
+ claims to have multi browser support https://devexpress.github.io/testcafe/documentation/using-testcafe/common-concepts/browsers/browser-support.html#officially-supported-browsers
+ can be used with page objects https://devexpress.github.io/testcafe/documentation/recipes/using-page-model.html#creating-a-page-model
+ can be used with cucumber https://github.com/helen-dikareva/testcafe-cucumber-demo
? uses a proxy between browser and server https://dzone.com/articles/testcafe-e2e-testing-tool
Why are they not using selenium https://dzone.com/articles/testcafe-e2e-testing-tool
? Selenium or TestCafe https://offbeattesting.com/2018/02/02/selenium-or-testcafe/

Nightwatch.js http://nightwatchjs.org/

+ multi browser support by selenium (should be similar, with similar limitations that what we do now)
+ cucumber plugin https://github.com/mucsi96/nightwatch-cucumber
+ support for page objects http://nightwatchjs.org/guide#page-objects
- problems with waiting
- problems with multi browser support if browser developers do not implement the protocol correctly
- basically all problems we have now with selenium
? uses selenium. We know selenium (the good, the bad and the ugly parts of it). I guess we get more or less the same what we have now with mink/selenium but in JS

CC: @felixheidecke @DeepDiver1975 @PVince81 @patrickjahns @phil-davis

Feature: download folder as zip

Story:
Given a user is logged in
When the user selects the file action 'download' on a folder
Then the folder is downloaded as archive (zip or tar)

Todos:

• Implement public server api (3MD)
• add action in files app (1MD)

Reusable Vue components provided by Phoenix

Challenges:

• how to load these in Phoenix apps ?
  • requirejs ?
  • import at compile time ?

@felixheidecke

file type icons

Story:

Given a user is logged in
When different files are uploaded
Then file type icons depending on the mime/type will be displayed

Give a developer is writing a theme
When the theme is holding custom file type icons
Then they need to be used

Tasks:

• Choose default file type icon set (source?) (0.5MB)
• Implement display of icons based on mime type (0.5MD)
• Respect Themability !!!! (0 MD)

please change license to AGPL

One Vue Instance to rule them all

The current state of Frontend/Phoenix application development is being questioned in the following:

Separate Instances - They dance alone

Sting - They Dance Alone

As of now, Phoenix Apps are standalone instances of whatever JS technology the developer decides on. Communication between apps and to Phoenix happens via APIs (OC.event) restricting apps NOT to know all the data, but instead receiving and requesting on a need-to-know basis.

E.g.: Apps that extend the files-app sidebar receive data about files/folders currently being selected. More data can be requested using the js-owncloud-client if needed.

Structural changes do not affect applications as long as the API stays the same, the latter can also live alongside a newer API until it reaches EOL.

Pros:

• You are free to use and write whatever you feel comfortable with as long as you follow the extension and API guidelines.
• you can determine what plugins can and can't do. Yes, there is a way around that but it's cumbersome and unstable.
• You can easily port your existing app over to Phoenix since "few" changes are necessary to run your app.

Cons:

• You will have to worry about offline-functionality for yourself as well as PWA support.
• You also have to create your own web pack config which can be a hassle if you are doing it for the first (and even 2nd and 3rd) time.
• Accessing all the things is hard to achieve if the necessary APIs don't exist.

Single Instance - Let's Stay Together

Al Green - Let's Stay Together

Phoenix already is a running Vue instance that can easily be extended in certain places by registering a new Vue Component.
Store and Router are at your disposal and can be extended, thus having r/w access to everything everywhere. Databinding works in the global context making all the apps reactive to changes by default.

Pros:

• A unified structure makes it easy for others to understand your app and extend an manipulate it in any possible way. It's the land of the free indeed!
• App bundles are smaller since you don't have to pack Vue and other frameworks do not apply anyways.
• You can keep certain data (kind of) private if you don't write it to the global store.

Cons:

• You better learn Vue.js or else you can't play with us.
• A Vue.js bug got fixed or feature was added in v2.5.16 but OC.Vue is still @ v2.4.11? Bad luck buddy!
• Files_App decided to rename filesList to fileList? Your (and probably 20 other) app(s) are likely to break in the next Files_App release.

What now?

The trend is leaning towards the unified approach as the pros outweigh the cons. The smallest changes have great effects, but professional deprecation management and RC releases give 3rd parties time to adapt.

Reviewing Apps by the OC Staff is easy since the structure and technology is known in-house.

Check out this demo of a unified Vue instance.

Support apps/plugins

We need a clearly defined mechanisms to allow frontend apps to properly hook into phoenix.

At best we allow to reuse existing web front ends like built in the contacts app as example.

Please make sure the #1 applies in here as well.

elements need unique identifier

to make UI tests easy and robust we need unique identifiers for every element that a test will interact with (e.g. buttons, links, form elements, lists, etc.)
preferable that unique identifier is an id (that is unique in every state of the page - just mentioning is because in core ids are re-used owncloud/core#27870)
If ids are not possible for any reasons we can use other attributes that are unique, e.g. name, data-attributes, css.

If there are no easy to use identifiers we have to build long, ugly xpath to locate the correct item on the page. That will make the UI tests:

1. unstable (we might have clicked the wrong button)
2. hard to maintain (the DOM changes and we have to change the xpath)

an article to read https://screenster.io/selenium-locators-best-practices/

Cleanup of scaffolding including docs, blog and stuff.

Story:
Give a developer want to work on Phoenix
....

Tasks:

• Final decision on vuetify vs uikit
• Cleanup of naming (uppercase function names - WTF) - partially addressed in oauth pr
• Cleanup on template language, script language and style language (keep it simple? html + ecma5 + css)
• Introduce style tools into drone - eslint

Total effort: 2 MD

Code AppLoader Mechanism

In order to register (setup) and load (boot) apps from within Phoenix, we need to assume a certain structure inside app's frontend code, as well as in Phoenix itself to ensure mutual functionality.

App

Based on the decision to use requre.js we require apps to present the boot.js which is to be written as a require modules exposing the following methods:

• info (obj)
  basic infos about the app
• setup() (func)
  Allows registering menu-entries and other preflight options. If "you" are a plugin, start your app here.
• boot() (func)
  mounting the application to the provided DOM node.

Phoenix

Likewise Phoenix exposes methods in the global OC class such as:

• registerNavItem()
• getConfig()
• getUserInfo()
• …

Booting

1. Phoenix calls all apps/*/boot.js --> *.setup() where dependencies are met.
2. Apps register whatever they need to register.
3. Phoenix prepares the DOM and calls whateverAppToLoad.boot().
4. And we are up and running.

Ignore package-lock.json files

I suggest ignoring the package-lock.json files altogether. They do not make sense as we pre-compile and pack Applications anyway instead of having the user compile it for themselves.

Pure web frontend

Phoenix should be a pure web frontend / web client.

In an ideal world we drop the front end into a web space for hosting and a config parameter (json file?) points the client to the existing owncloud backend instance.

Adapt Phoenix to PWA (Progressive Web Application)

Hi,

in order to make Phoenix more reactive to the user, following PWA guidelines is a good approach.
The lighthouse tool can be used to audit different dimensions of the application for further optimizations.

The results I have got after running, are shown below:

The aspects identified for improvement are the following:

• Does not respond with 200 when offline (use service workers for serving the shell app)
• Does not provide content fallback when JS is not available (provide HTML alternative)
• Does not redirect HTTP to HTTPS (not a dev task)
• Page load is not fast enough on 3G networks (reduce the library size)
• Users are not prompted to install the app (create web app manifest)

File viewer and editors

Story:
Given a developer want to add an action to open a file in another tool
When the app code registers a file action for text files
Then the action shall be visible on text files

When a user executes the file action
Then app code is to be executed or a given url is to be opened (in another tab)

Tasks:

• implement file action + viewer concept in phoenix files app (3MD)
• implement an app to show (text editor which opens a text file in new browser tab) (2MD)

---

Like owncloud/core#13414.

Provide an extension point of some form where apps can register their own "file viewer" for different formats.
This will tie in somehow with the file actions

Please add input as we need to decide on the UX for this.

One proposal was to always have apps open their viewer in a separate page.
This also means the separate page needs to have some layout and styling from Phoenix.

@felixheidecke @DeepDiver1975 @tomneedham @pmaier1

Search files

• filter files in current folder based on file name pattern
• search in files in multiple folders: integrate with https://github.com/owncloud/documentation/issues/4241 to provide the ability to search for files in multiple folders

It is not clear yet whether we still want to have a global search field at the top right which is supposed to search more than just files (also calendars, contacts) or have another field in the files app for files-only search.

Partial loading of file list

The file list in a directory should not be loaded at once when the directory has large number of sub-folders and files. It could increase the loading period leading to bad user experience.

However there isn't any method in the owncloud/js-owncloud-client yet that could be used to achieve this task.

Project Overview first app release

Tasks that need to be taken care of:

• Single Vue Instance est. 1d
• Sharing sidebar app est. 3d
• Authentication layer est. TBD => likely too much, let's focus on basic auth for the first version
• Allow apps to register to a connected event est. 2h
• elements need unique identifier est. 1/2 day
• js-owncloud-client packaging

Sidebar doesn't open

Steps

1. Check out master
2. Run make run
3. Login to a server that have CORS enabled
4. Create a folder "test"
5. Click on the right of the folder "test" to open the sidebar

Expected

Sidebar opens

Actual

JS error:

files.bundle.js:9 Uncaught TypeError: e.singleSelect is not a function
    at click (files.bundle.js:9)
    at t (core.bundle.js:14)
    at HTMLTableCellElement.Dr.t._withTask.a._withTask (core.bundle.js:14)

@felixheidecke

Fix vuejs browser extension

The chrome browser extention can currently no be enabled.

reason: vuejs is bundled into core.bundle.js

Add a nice screenshot in README

Localization support

• need to bundle the translation files from transifex
• Vue needs a way to use said texts (probably an extension)
• also have numbers use the locale, maybe use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat

Wrapper to deliver Phoenix as marketplace app for 10.0

We could put the files app component into a separate frontend app that can be delivered over marketplace.

Or should we deliver the whole layout ?

File uploads with chunking and resumable

We should look into using http://www.resumablejs.com/ for Phoenix.

Don't pick up the old upload code from core as it uses jquery.fileupload and needs to much hacking around to make it work with our chunking.

App menu: allow registration of simple url which is to be opened in a new tab

Use case:

• documentation or help systems are to be made available for the user
• integration with integrated 3rdparty systems (like webmailer etc)
• integration with existing apps as of today

ToDo:

• allow to add name, icon and url to config.json
• allow phoenix apps to register a app entry with a url to be opened in a second tab

Node.js vs. native ES6 support

I am currently weighing using node.js vs the native ES6 support in current browsers. Why? you ask?

Using node would allow us to easily read from the filesystem, scan folders and all the crazy good stuff, such as having the apps simply expose what we need to render it to the right place in the dom. All the scaffolding such as app loading could be done in ES6 and we still could support IE11 since all the crunching is done on the node server. We wouldn't even need Apache, IIS or whatever. Just node. Since the latter is written in JS, it opens up native endpoints in the webserver too.

The native ES6 support in Browsers is very limited. We "only" can load javascript from the filesystem (no reading form the package.json for example) and they would have to be written in a specific way for exposition to work.
This would of course not be supported by IE11.

I am currently working out a way not using node and see how much we are able to accomplish using this approach. I'll keep you posted.

@PVince81 @DeepDiver1975

File actions API

A Phoenix app must be able to register custom file actions with handlers.

See the FileActions JS class in core to get an idea:

• FileActions, the registry for all file acitons: https://github.com/owncloud/core/blob/master/apps/files/js/fileactions.js#L29
• FileAction the object to specify actions: https://github.com/owncloud/core/blob/master/apps/files/js/fileactions.js#L717

@felixheidecke we might want to chat about this at some point

Marketplace app

Code must be organized in a way that we can bundle Phoenix as a marketplace app.

To be discussed:

• do we only want the files app / individual phoenix apps ?
• or do we want the full frontend, navigation, layout to be able to be installed

In the latter case we need a switch somewhere in OC core to let the app take over the full layout.
Or simply provide a checkbox in the login page to "Login into Phoenix" in which case only Phoenix apps are available at first.