{"action":"created","issue":{"url":"https://api.github.com/repos/owncloud/core/issues/19331","labels_url":"https://api.github.com/repos/owncloud/core/issues/19331/labels{/name}","comments_url":"https://api.github.com/repos/owncloud/core/issues/19331/comments","events_url":"https://api.github.com/repos/owncloud/core/issues/19331/events","html_url":"https://github.com/owncloud/core/issues/19331","id":108085914,"number":19331,"title":"Sharing 2.0 proposal","user":{"login":"rullzer","id":45821,"avatar_url":"https://avatars.githubusercontent.com/u/45821?v=3","gravatar_id":"","url":"https://api.github.com/users/rullzer","html_url":"https://github.com/rullzer","followers_url":"https://api.github.com/users/rullzer/followers","following_url":"https://api.github.com/users/rullzer/following{/other_user}","gists_url":"https://api.github.com/users/rullzer/gists{/gist_id}","starred_url":"https://api.github.com/users/rullzer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rullzer/subscriptions","organizations_url":"https://api.github.com/users/rullzer/orgs","repos_url":"https://api.github.com/users/rullzer/repos","events_url":"https://api.github.com/users/rullzer/events{/privacy}","received_events_url":"https://api.github.com/users/rullzer/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/owncloud/core/labels/discussion","name":"discussion","color":"fbca04"},{"url":"https://api.github.com/repos/owncloud/core/labels/feature:sharing","name":"feature:sharing","color":"d4c5f9"},{"url":"https://api.github.com/repos/owncloud/core/labels/overview","name":"overview","color":"fef2c0"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/owncloud/core/milestones/48","html_url":"https://github.com/owncloud/core/milestones/9.0-current","labels_url":"https://api.github.com/repos/owncloud/core/milestones/48/labels","id":1196845,"number":48,"title":"9.0-current","description":"","creator":{"login":"cmonteroluque","id":879976,"avatar_url":"https://avatars.githubusercontent.com/u/879976?v=3","gravatar_id":"","url":"https://api.github.com/users/cmonteroluque","html_url":"https://github.com/cmonteroluque","followers_url":"https://api.github.com/users/cmonteroluque/followers","following_url":"https://api.github.com/users/cmonteroluque/following{/other_user}","gists_url":"https://api.github.com/users/cmonteroluque/gists{/gist_id}","starred_url":"https://api.github.com/users/cmonteroluque/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cmonteroluque/subscriptions","organizations_url":"https://api.github.com/users/cmonteroluque/orgs","repos_url":"https://api.github.com/users/cmonteroluque/repos","events_url":"https://api.github.com/users/cmonteroluque/events{/privacy}","received_events_url":"https://api.github.com/users/cmonteroluque/received_events","type":"User","site_admin":false},"open_issues":553,"closed_issues":423,"state":"open","created_at":"2015-07-07T14:21:23Z","updated_at":"2015-11-23T13:19:54Z","due_on":"2016-02-09T05:00:00Z","closed_at":null},"comments":59,"created_at":"2015-09-24T08:45:41Z","updated_at":"2015-11-23T13:46:43Z","closed_at":null,"body":"@schiesbn and myself spend some time at the conference coming up with a possible design for sharing 2.0. Here is basically an overview of my notes.\r\n\r\n\r\n## Note\r\n\r\nAs discussed in Berlin the sharing stuff will for now only be for files. Contact and calendar will use the old sharing code but will be moved to webdav.\r\n\r\n## Architecture\r\n\r\nWe want to move all real sharing to separate apps. Right now sharing is mostly in core and this is not really the right place. It makes it hard to have custom sharing implementations.\r\n\r\nWe propose a single `sharemanager` in core where apps can register themself. Furthermore in core we will provide a number of interface that apps have to implement in order to become a `shareprovider`. \r\n\r\nCurrently we have the following 3 categories of shares:\r\n* user/group\r\n* link\r\n* federated\r\n\r\nWe will of course keep those 3 categories but each of them will be a separate app. This would mean we would get more core apps. Which will take some time but in the end we should end up with a more modular (and better maintainable) sharing setup.\r\n\r\nWe will then also need another new app that handles the OCS Sharing API. This clearly separates the API and the sharing implementation \r\n\r\n### No more sharing hierarchy\r\n\r\nWe propose to move to what we like to call a flat sharing model. This will prevent cyclic sharing or at least make sure it is no longer an issue. (see also https://github.com/owncloud/core/issues/9058)\r\n\r\nThis effectively means that shares are a combination of the following items\r\n* path\r\n* share owner (owner of the path)\r\n* sharer (initiatior of the share)\r\n* sharee (receiver of the share)\r\n* permissions\r\n\r\nThis means that the share owner always has the complete overview of who has access to a share.\r\nAnd that we can easily find out the max permissions for a sharee.\r\n\r\n\r\n### Interfaces\r\n\r\n#### sharemanager\r\n\r\nThe share manager is just a place where `shareproviders` can register and where they can be queried. There will be some functions to get a specific share or to get a traversal of all shares in a path etc.\r\n\r\n#### shareprovider\r\n\r\nThe share provider just implements sharing for a specific type. You can of course tell the provider to share a file. Or to get a share etc.\r\n\r\nEach share provider has a unique id.\r\n\r\nWe plan to have two share providers:\r\n\r\n1. \"internal share provider\" which will be provided by the primary storage and handle (user, group and link sharing)\r\n2. \"federated share provider\".\r\n\r\nIn general share provider will register them self at the share manager. This way it is easy to develop and add new share provider. For the internal share provider (which could be seen as the main share provider) the share manager will ask the primary storage directly to provide it.\r\n\r\nWe will implement two share providers as apps, the \"oc internals share provider\" which does sharing basically as we are doing it today and the \"oc federated share provider\". Bot will register them self at the share manager if the apps are activated. Additionally the share manager will ask the primary storage if he implements his own share provider. If he returns a share provider it will be used for internal shares, if it returns false the \"oc default internal share provider\" will be used. That's also the reason why the \"oc default share provider\" needs to be implemented as a app and not as part of our default storage, because the share provider needs to be also available for other storage if they don't implement their own share provider.\r\n\r\n#### share\r\n\r\nJust an object representation of the share. Where you can get and set the attributes etc.\r\n\r\nEach share withing a shareprovider has a unique id.\r\n\r\nA system wide unique id could be constructed as \"providerID#localShareID\" or something similiar.\r\n\r\n#### Example Code\r\n\r\nI took the liberty of already starting with some interfaces:\r\n\r\n[ShareManager](https://github.com/rullzer/core/blob/sharing2.0_start/lib/public/share/imanager.php)\r\n[ShareProvider](https://github.com/rullzer/core/blob/sharing2.0_start/lib/public/share/iprovider.php)\r\n[Share](https://github.com/rullzer/core/blob/sharing2.0_start/lib/public/share/ishare.php)\r\n\r\n## Limitation\r\n\r\nWe can only handle 1 share provider per type.\r\n\r\nDuring the conference we had the idea to do things on a per storage level. But this brings in a lot of problems. Assume there are 2 folders `dirA` and `dirB`. Now the storage where `dirA` lives supports link sharing but the storage of `dirB` does not. Now what happens if a file with link share is moved from `dirA` to `dirB`?\r\n\r\nIn general most people will just use the apps that we provide. And in the case that people want very specific sharing behaviour for certain storages they should write their own sharing apps. \r\n\r\nForcing this limitations keeps things simple and understandable and we do not believe this to be a limitation a lot of people will have problems with.\r\n\r\n## Migration/deprecation path\r\n\r\nFor third party apps like calendar and contact we will move the existing sharing code to the apps and will make them work. From this point on the app delevlopers have to maintain or replace the existing code.\r\n\r\nFor file sharing we will re-use the exiting table, update the values add needed columns and remove old columns we no longer need at the end. The idea is that this process will be triggered with a occ script after the main upgrade to 9.0 while the system is live (still need to evaluate if this is possible).\r\n\r\nOpen Question:\r\n\r\n- [ ] What happens for small installations with no access to a terminal? We probably need a fall back to trigger this update in the admin settings (similar to what we do for encryption key migration)\r\n- [ ] When we migrate the shares step by step on a running system re-shares will not be visible until they are migrated (sync clients will potentially delete local copys and download them later again if the re-share shows up again)\r\n\r\n## Improvements\r\n\r\nSince we kind of start over. There are a lot of things where we can improve and unify the current sharing design. Some things we came up with.\r\n\r\n### Expiration date on everything\r\n\r\nCurrently it is only possible to have expiration dates on link shares. There is no real technical reason for this and it is perfectly valid to have other shares expire as well. \r\n\r\n### Multiple link shares\r\n\r\nCurrently only 1 link share is allowed per file. Having multiple makes sense since I might want to share a file with multiple people but not for the same period of time. This could be combined with easily sharing via email so the individual link is automatically sent to the respective person. Individual links can then also be revoked easily based on email/name.\r\n\r\n## Open Issues\r\n\r\n- [ ] decide about the right default permission for shares https://github.com/owncloud/core/issues/11707#issuecomment-143165474\r\n\r\n## Checklists\r\n\r\n- Share backend\r\n  * [ ] Share manager ( https://github.com/owncloud/core/pull/19872)\r\n    * [ ] Throw delete hooks (https://github.com/owncloud/core/issues/20543)\r\n    * [ ] Delete all children of share on delete (https://github.com/owncloud/core/issues/20543)\r\n    * ** TODO Add list **\r\n    * [ ] allow to pass in a token when creating a new share\r\n  * [ ] Default share Provider\r\n    * [x] List share (https://github.com/owncloud/core/pull/19872, https://github.com/owncloud/core/pull/20356)\r\n    * [x] Delete share (https://github.com/owncloud/core/pull/19872)\r\n    * [x] Get children (https://github.com/owncloud/core/pull/19872)\r\n    * [ ] Update Share\r\n    * [ ] Create Share\r\n      * [ ] Link Share (https://github.com/owncloud/core/issues/20613)\r\n      * [ ] User Share\r\n      * [ ] Group Share\r\n  * [ ] Federated Share Provider\r\n    * [ ] List share \r\n    * [ ] Delete share\r\n    * [ ] Get children\r\n    * [ ] Update Share\r\n    * [ ] Create Share\r\n- Move OCS Share API to new sharing code\r\n  * [x] Delete Shares (https://github.com/owncloud/core/pull/19872)\r\n  * [x] List single shares (https://github.com/owncloud/core/pull/20356)\r\n  * [ ] List multiple shares\r\n  * [ ] List shares shared with me\r\n  * [ ] Update shares\r\n     * [ ] User shares\r\n     * [ ] Group shares\r\n     * [ ] Link Shares\r\n  * [ ] Create Shares\r\n    * [ ] User Share\r\n    * [ ] Group Share\r\n    * [ ] Link Share (https://github.com/owncloud/core/issues/20613)\r\n    * [ ] Federated share\r\n\r\n## How we implement it\r\n\r\nThe idea is to implement it in parallel to the existing sharing with small pull request merging sharing 2.0 one by one. In this transition phase it will be possible to switch between old and new implementation for testing purpose. Only if sharing 2.0 is complete and works reasonable well (including all integration tests for the OCS API) we will move the old sharing to the calendar and contacts app like explained under \"Migration\" and switch permanently to the new sharing.\r\n\r\n## Related issues:\r\n- https://github.com/owncloud/core/issues/13014 : previous sharing 2.0 issue\r\n- https://github.com/owncloud/core/issues/17861 : Allow filtering of shares list\r\n- https://github.com/owncloud/core/issues/13202 : Share permission issues\r\n- https://github.com/owncloud/core/issues/9058 : Resharing behaviour\r\n- https://github.com/owncloud/core/issues/5491 : Avoid loop shares\r\n- https://github.com/owncloud/core/issues/20582 : OCS API /shares/id should also return for shares with me"},"comment":{"url":"https://api.github.com/repos/owncloud/core/issues/comments/158936608","html_url":"https://github.com/owncloud/core/issues/19331#issuecomment-158936608","issue_url":"https://api.github.com/repos/owncloud/core/issues/19331","id":158936608,"user":{"login":"PVince81","id":277525,"avatar_url":"https://avatars.githubusercontent.com/u/277525?v=3","gravatar_id":"","url":"https://api.github.com/users/PVince81","html_url":"https://github.com/PVince81","followers_url":"https://api.github.com/users/PVince81/followers","following_url":"https://api.github.com/users/PVince81/following{/other_user}","gists_url":"https://api.github.com/users/PVince81/gists{/gist_id}","starred_url":"https://api.github.com/users/PVince81/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/PVince81/subscriptions","organizations_url":"https://api.github.com/users/PVince81/orgs","repos_url":"https://api.github.com/users/PVince81/repos","events_url":"https://api.github.com/users/PVince81/events{/privacy}","received_events_url":"https://api.github.com/users/PVince81/received_events","type":"User","site_admin":false},"created_at":"2015-11-23T13:46:43Z","updated_at":"2015-11-23T13:46:43Z","body":"> from my pov we will need string because of all discussed reasons - but this would require v2 of the sharing api which I'd like to postpone for now (maybe a topic for 9.1).\r\n\r\nAgreed. Also changing int to string on the interfaces later shouldn't be a big change (or introducing new interfaces). The biggest part is making sure the clients can still work with string ids."}}