Core: ownCloud Platform - Planning

Created on 18 May 2016  Â·  43Comments  Â·  Source: owncloud/core

Hello Everyone,

For quite some time now, the ownCloud release definition and planning process has been largely hidden behind a curtain. On behalf of the entire ownCloud company, we are pleased to announce that as of today, this is changing.

I will be back before long with more information shortly - but first I needed the link.

discussion overview

Most helpful comment

Separate favorites from syncing, and complete mobile syncing of files and folders

  • Category: Mobile Sync / End User Experience
  • Link to GitHub issue with discussion: https://github.com/owncloud/android/issues/1677
  • Quick summary use case: As an ownCloud user, I want to sync files across mobile devices so that I can always have the latest files available in the same way, fully, whether online or offline
    Problem it solves / Why I think this is important: ownCloud provides a file sync interface, the current sync capabilities are somewhat confusing to end users with files not being synced

All 43 comments

To continue what I started above, I made a proposal in this blog https://owncloud.org/blog/owncloud-inc-announces-open-planning-process/ . As discussed in the blog, I created this issue as a placeholder for discussing the next release of the ownCloud platform. What is the ownCloud platform? Think of it as a shortcut meaning the combined desktop, mobile and server components – in a sense, all of ownCloud. This issue as a place where we all discuss what we would like to see in upcoming releases of ownCloud, both across and within components.

As an example, I have already added one comment below for consideration in ownCloud, which is to harmonize the favorites feature of the server with the mobile and desktop platforms, so that favorites mean the same thing wherever you are on the platform, and that your favorite files are available wherever you are on the platforms. This is just one idea, and certainly not the only one.

Anyone can add other ideas to carry on the discussion about the future of ownCloud. To add an idea to the ownCloud list, simply add the following information as a new comment in this GitHub issue:

  • Title: Permalinks
  • Category: e.g. Sharing and Share Links
  • Link to GitHub issue with discussion: #123456
  • Quick summary use case: xyz
  • Problem it solves / Why I think this is important: Reason abc

Then all of us can vote on a given issue using the heart button. The more hearts, the higher the priority.

On May 30, we will begin to create a new Github issue to begin the specific conversation around the next release of ownCloud, likely this will be server 9.2 and associated mobile and desktop clients.

If you already have an existing enhancement, simply add a comment to the GitHub issue and link to the existing issue. If you see an enhancement you would like, do the same. If you see something you would like to add to an enhancement on the list, please do so. This is an open forum for conversation and planning, and we welcome input – and in particular we LOVE use cases, they help us understand what you are trying to do.

Make favorites the same on mobile, desktop and server

  • Category: End user experience
  • As an ownCloud user, I want favorite files within mobile to be the same as favorites on the server, and potentially also the desktop, to find the important files and folders I care about fast. While the favorite icon / tag is synced across platforms for a file or folder, a favorite file is not automatically synced. This file sync is available via a second user story.
  • https://github.com/owncloud/core/issues/24671
  • Currently favorites are a confusing feature that we use in different places to mean different things (mobile favorites are not the same as server favorites, and server favorites do not sync but mobile favorites do). By normalizing favorites, the user experience will be improved across the board.

Separate favorites from syncing, and complete mobile syncing of files and folders

  • Category: Mobile Sync / End User Experience
  • Link to GitHub issue with discussion: https://github.com/owncloud/android/issues/1677
  • Quick summary use case: As an ownCloud user, I want to sync files across mobile devices so that I can always have the latest files available in the same way, fully, whether online or offline
    Problem it solves / Why I think this is important: ownCloud provides a file sync interface, the current sync capabilities are somewhat confusing to end users with files not being synced

Accepting local shares explicitly (like for federated shares)

  • Category: Sharing
  • Github issue: https://github.com/owncloud/core/issues/19153
  • Use case: be able to confirm/accept incoming shares instead of letting people clutter my home directory with shares / be consistent with federated shares. By extension, when added to a group share, be able to reaccept group shares.

Thumbnail Gallery in the mobile Client

Category: Mobile Client iOS (and probably android)
Github issue: #24711
Use case: To be able to watch photos in the mobile client without syncing/loading all of these photos to the obile device. Especially on greater photo collections (>100GB) an easy watching/browsing is not possible, since you cannot download all photos to your device (storage space, limited bandwidth) prior watching.

Comparable feature exists already in the webinterface of owncloud gallery.

Fix ownCloud Music for large collections

I get unresponsive pages since the application finished scanning my collection.
(Stuck with a loading gif.)

  • Problem it solves / Why I think this is important: ownCloud needs to seriously consider multimedia content, otherwise, as a power user, we'll need at least two open webapps to manage our data. Isn't that redundant? Maybe RabbitMQ is needed to solve this issue or am I wrong?

Improve security by adding One-Time-Password (OTP) / Two-Factor Authentication

  • Category: Authentication / login
  • Link to GitHub issue (existing, discussion limited to collaborators): owncloud/core #12102
  • Quick summary use case: Allow two-factor authentication in case of login via web browser; in the case of the app/clients it should be asked only the first time and a long, complicated secret should then be generated and used in the future (the issue is already full of good ideas)
  • Problem it solves / Why I think this is important: it improves security significantly, and I consider it a standard feature of modern cloud storage (Google and Dropbox already support this)

=> done with the TOTP apps, two factor is supported

Improve fed sharing performance.
There are known issues to which fixing is more complex than simple bugfixes and need proper scheduling.

  • Category: Federated sharing
  • Github issue: https://github.com/owncloud/core/issues/13882#issuecomment-73927046
  • Quick summary: As a user I expect accessing files from federated shares to not be significantly slower than files on a local share for a seamless experience
  • Why I think it's important: over time, it is likely that more and more people are going to use federated shares as it's a neat feature. This means there will be more traffic between ownCloud instances so it would be good to optimize that traffic to be more efficient. (see ticket for details about known issues)

=> many speed improvements added in OC 10.0

Improve external storage performance (with streaming instead of using temp files).
Currently most ext storage backends resort to temp files on upload which increase the likeliness of timeouts with big files.

  • Category: External storage / Performance
  • Github issue: https://github.com/owncloud/core/issues/5949
  • Use case: As a user I expect that accessing files from any external storage is as fast as (or close to) accessing local files. In general a user shouldn't have to care about where the files are stored.
  • Why I think it's important: as a developer I see many potential improvements in the current approach, especially for uploads. Also, with bigger transfers the likelihood to run into PHP timeouts is increased, so improving the way how upload works for ext storages would help reduce such occurrences.

Add a lock button or password lock! That will help to avoid the administrator to modify the expert tab in productive systems.

Category: LDAP authentication.

Github: https://github.com/owncloud/enterprise/issues/1327, https://github.com/owncloud/enterprise/issues/1175, https://github.com/owncloud/enterprise/issues/1166, https://github.com/owncloud/enterprise/issues/235, https://github.com/owncloud/enterprise/issues/530,https://github.com/owncloud/enterprise/issues/832, https://github.com/owncloud/enterprise/issues/525, just to name some of them.

Use case: Administrator modifies the expert tab in the production system "BY MISTAKE" Because its not locked.

Why: because it happens often and nobody reads the documentation.

The documentation explains it: cleaning the mapping:

In the Expert Settings fundamental behavior can be adjusted to your needs. 
The configuration should be well-tested before starting production use.

Transmission checksum validation on the server to ensure data intergrity.

  • Category: Reliability
  • Github issue: https://github.com/owncloud/core/issues/11811
  • Use case: As a user I want to upload files with transmission checksums to ownCloud. In order to detect errors in transmissions. I want my data to be safe.
  • Why I think it's important: right now the server only passes those checksums around. This does actually not protect against corruption as it is only verified if a different client download it later.

=> done in OC 10.0

Metadata sync: Update metadata if no content change happened

  • Category: Reliability
  • Github issue: owncloud/client#4755 , #20474
  • Use case: As a user I want to get the meta data synced without uploading the file content again
  • Why I think it's important: Syncing content if it is not neccessary is wasting time and bandwidth

Title:
advanced and improved logging

Category:
core / administration

Link to GitHub issue with discussion:
none, yet

Quick summary use case:
advanced error log in the administration panel with two main objectives
1) advanced logging
havent looked into the code so far, perhaps we don't even need to change much of here - id be not very impressed if theres already a lot more of information gathered or at least easily available.
but just if not heres what im thinking of what should be implemented: url, path to file tried to open / path to script, user session details _(name, ID, session, useragent etc.pp.)_ and lotta other stuff like IP address _(not just for failed logins and make it optional at best (privacy))_
2) improved UI
of course all the above mentioned information should be shown somewhere. im thinking of adding the path/url, while stuff like session/user info could be shown as a tooltip
also im missing a "delete log" button for eons _(delete each seperate entry like for files would be awesome)_ and excessively long include() errors are both totally unnecessary AND most often useless :)

Problem it solves / Why I think this is important:
by far im not a power user nor that ive got more than 5 active user in my owncloud, but its been like a few dozen times that i wished to know more about an error. whether its debugging, playing around with the config or just to find out which specific share/link/gallery gets lots of "wrong password" errors _(Exception: Missing password is absolutely irrelevant without knowledge of the path)_

Furthermore a lot of dependencies like specific versions of libraries, PHP functions or even used linux binaries are hidden to the end user and ownCloud is just silently failing (https://github.com/owncloud/core/issues/14092) which is quite bad from UX perspective.

Automated and comprehensive tests for sync client

  • Category: Reliability
  • Github issues and pages : tests for propagator jobs, current tests, long running tests
  • Use case: As a user I want to update my client to the latest version with the shiny new features without worrying about data loss, regressions, early bugs, etc.
  • Why I think it's important : fully automated tests will increase the reliability of the code shipped, reduces the amount of time spent on manual QA, and make the integration of community-contributed code faster and less risky. Tests exist today but they are not automated (perl, smashbox) and not comprehensive (linux-only support, no error-handling tests, no multiple clients/servers combo tests).

Edit : removed the part about smashbox not being automated since it is.

Expiration of internal user shares.

  • Category: Sharing
  • Github issue: https://github.com/owncloud/core/issues/11642
  • Use case (from the ticket): As a user, I want to be able to set expiration dates on internal shares in ownCloud, separate from an expiration for external share links, so that I can control who can access my files for how long.
  • Why I think this is important: not sure, but people should comment in the ticket :smile:

Assure that files are uploaded to the server to protect user data.

There is a number of cases where files should be synced but are not. This is to prevent accidental data loss for the users and make it easier to support large user base.

  • Remove least-common OS-denominator restrictions in sync client for filenames. For example, due to the fact that ":" character cannot be used on Windows, my MacOSX sync client refuses to upload such files. For a user that only has a Mac and Linux clients this is a limitation is not valid nor understandable.
  • Upload conflict files which currently only exist locally and any local modifications may potentially be lost.

Note: in the first phase it is enough to guarantee that the files are just uploaded to the server (without a need to download them to another client). This makes the implementation relatively easy and achieves the data protection goals.

Collect client information to provide better user support.

An admin of a large instance should be able to automatically inspect the configuration of the sync client, version, recent activity log of the sync client and possibly debug output for a chosen user. Such a report (maybe also including basic OS information such as OS type and version) could be uploaded as a set of (hidden) files to the instance when triggered by an admin. Having such information at hand would be much easier to debug problems, provide better user support for large user bases and understand how users configure their sync clients to improve the service.

Note: since the user trusts the admin with their files already there is no problem also to trust them with diagnostic information about the functioning of the sync client. Existing, trusted connection to the server should be used (and not any other parallel communication channel which could be a potential attack vector).

Central configuration of the sync clients by the service admin.

It should be possible to provide sync clients with centrally managed configuration parameters. There are two cases:

  • advertising server capabilities or preferences: e.g. checksum type, default chunk size, client poll interval for remote changes
  • client configuration: e.g. list of ignored file patterns, default remote sync folder location for new clients etc.

Casual users should not worry about setting such parameters (hardcoded client defaults used as it is done today). Advanced users or admins of large instances should have such a flexibility (but they do not necessarily need a server GUI to do it).

Self created groups

  • Category: Sharing
  • Link to GitHub issue with discussion: #24825 #8201
  • Quick summary use case: Create groups out of usernames you already shared with or you have imported from a text file.
  • Why I think it's important: In a sync and share tool, sharing should be as easy as possible. There are several users not using our service because this feature is missing.

=> done with custom groups app

Get mess with update notification / updates via the updater app finally sorted out

  • Category: User experience
  • Link to GitHub issue with discussion: https://github.com/owncloud/core/issues/24827
  • Quick summary use case: It should be made transparent to the end-user why updates via the updater app are delayed / not available
  • Why I think it's important: Since years it is not transparent to the end-user why updates or upgrades are not made available via the updater app. In the current case the updater app has a bug (https://github.com/owncloud/updater/issues/350) causing this delay. However no information about this is provided officially. The end-user only sees that there is no update available.

=> updater code was moved to https://github.com/owncloud/administration/tree/master/update-server

Android: Show images without downloading full image

  • Category: Android
  • Link to GitHub issue with discussion: https://github.com/owncloud/android/pull/1599
  • Quick summary use case: Show (and store in cache) resized, screen adapted images rather than download every full image.
  • Problem it solves / Why I think this is important: User can save bandwith and storage when they just want to browse through images and share these resized (~40kb) images with e.g. whatsapp, Facebook as the quality is most time good enough.

Send password automatically when sharing via e-mail

  • Category: Sharing, Security
  • Github issue: https://github.com/owncloud/core/issues/11682
  • Instead of having to send the password in a seperate email we should do it automatically. This could be done in a seperate email with the password that the admin provided, or a one-time-password.
  • Why I think this is important: Easier administration when sharing with password.

Give https://apps.owncloud.com some more love

=> marketplace was done and replaces the old app store

Title: AUTOLOGOUT for MULTI-USER
Category: User Experience
Link to GitHub issue with discussion: #640
Quick summary use case: Using owncloud within a school district on shared IOS devices, Autologout after device has been locked for so many minutes
Problem it solves / Why I think this is important: Because we are sharing iOS devices between students and teachers, the ability to have it Auto-logout would preserve data integrity/privacy. Leaving it to the user to remember to log out is not reliable

The need of a more distinct communication strategy: https://github.com/owncloud/core/issues/24864#issuecomment-222305707

Add functionality for tagging multiple files at once

Category: End user experience
Github issue: #22969
Use case: Tagging a lot of files is really time consuming. Having the possibility to give the same tag to all the selected files improves a lot the situation

Add a search function to shared gallery

Category: Gallery
Link to GitHub issue with discussion: https://github.com/owncloud/gallery/issues/36
Quick summary use case: When a user share a picture gallery, it isn't yet possible to search in the shared gallery.

Problem it solves / Why I think this is important: I have a big gallery with hundreds of picutures in each folder. When I share this gallery the other user is able to search for a specific filename quikly. Unit now the user has to search manually in each folder, which is many many work (and wouldn't be done because of time comuming)

Exclude server-side folders from syncing (ex: snapshots)

Category: Syncing Internal filesystem
Github issue: PR https://github.com/owncloud/core/pull/19235
Use case: Admins might have local snapshots in user's folders, these must not be synced
Problem it solves: see https://github.com/owncloud/core/pull/16534#issue-79443413

This was already submitted as PR a long time ago by @mmattel and needs to be finalized and reviewed.

@PVince81 from my POV we should differenciate syncing versusscanning/internal processing

  • #19235 and #16534 is scanning and internal processing (and therefore can not by synced anyway, because internally not present) while
  • #7234 is exclude from syncing with the sync client (internally and externally present, browser, webdav ect but not via the sync client)

Admin (ownCloud side) driven ability to exclude external storage mounts from being synced by the sync client

Category: Sync with the sync client
Github issue: #7234
Use case: Exclude from the owncloud admin side (not from the user side!) the ability to sync a mountpoint. An excluded mount point will not show up on the sync client as syncable source.

Improve the Updater App

Category: Updater
Github issue:
https://github.com/owncloud/updater/issues/202
https://github.com/owncloud/updater/issues/304
https://github.com/owncloud/updater/issues/311
https://github.com/owncloud/updater/issues/312
https://github.com/owncloud/updater/issues/341
https://github.com/owncloud/updater/issues/342
...and more
Use case: overall improvement of handling, the UI, ability to run pre and post scripts (eg to prepare the instance), better differentiation between core and updater tasks ect

App information consolidation

Consolidate the apps space, where information about an app comes from a single source of reference that is the same for every app, e.g. the appinfo area in the repository.

Current situation: different places about apps differ in the information they provide, eventhough they apparently should say the same:

  • https://apps.owncloud.com,
  • the server-included Apps area (myserver.tld/index.php/settings/apps) and
  • github-repo/appname/appinfo/info.xml, etc.
  • ...

Examples: Bookmarks, Mail

Annoyance: As a user/contributor it does not make any sense, if I need to look at all of these places (and maybe more) if I want to find something. Furthermore it carries the risk of inconsistencies. As a developer I have to maintain all of these places (an should not forget any)!

Potential solution: make github-repo/appname/appinfo the central point of reference where all others draw their information from (ideally fully automatic).
_Potential enhancement: move the doc-section for an app from https://github.com/owncloud/documentation to the apps repository, like github-repo/appname/doc/, and let the build process draw it automatically from there - to create a consistent and complete app package in the repo_

Desired result:

  • improved UX, through consistent, reliable and easy to find information about apps for Users, Admins, Developers, Contributors
  • reduced maintenance effort for developers (of all these areas)

_Note:_ with some support from the stakeholders of the existing structures and from a coder for the automatisations I would offer to develop the concept, implement it and adapt the existing stuff. See https://github.com/owncloud/appstore-issues/issues/8 as well.
Might be related to the http://apps.owncloud.com topic by @RealRancor above, too.

Should this be moved to central ? We might lose the votes though: http://central.owncloud.org/

The advantage of central is that even people without Github account can comment (there's a twitter login as well)

@RealRancor @tflidd what do you think ?

I doubt fellows interested in OC development are significantly more involved in Twitter than in Github. Is it worth to relocate it?

Registering at Github is a nobrainer..

Torben

@TDannhauer not everyone is a developer but still might want to discuss features :smile:

Judging on the number of votes in this issue, I think these were mostly developers. So there is probably more participation on central.owncloud.org.

I’m fine with both solutions.

Von: Vincent Petry [mailto:[email protected]]
Gesendet: Freitag, 22. Juli 2016 09:26
An: owncloud/core [email protected]
Cc: Torben Dannhauer [email protected]; Mention [email protected]
Betreff: Re: [owncloud/core] ownCloud Platform - Planning (#24684)

@TDannhauer https://github.com/TDannhauer not everyone is a developer but still might want to discuss features 😄

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/owncloud/core/issues/24684#issuecomment-234473437 , or mute the thread https://github.com/notifications/unsubscribe-auth/AGZ6gYIhPwWPSi8lZE5zAt8Rr8urTFKeks5qYHCLgaJpZM4Ig9aP . https://github.com/notifications/beacon/AGZ6gfv_RF4xFgpYf7gZYEAwr2SGxwYLks5qYHCLgaJpZM4Ig9aP.gif

I went through the list again and edited those that were done in OC 10.0.

Here they are:

I'm closing this ticket now, let's continue tracking feature requests and votes on central

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dpeger picture dpeger  Â·  3Comments

tommis picture tommis  Â·  5Comments

jnweiger picture jnweiger  Â·  4Comments

rehoehle picture rehoehle  Â·  4Comments

jvillafanez picture jvillafanez  Â·  4Comments