Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let apps register Sabre plugins or collections #26761

Merged
merged 3 commits into from
Dec 6, 2016

Conversation

PVince81
Copy link
Contributor

@PVince81 PVince81 commented Dec 2, 2016

Description

See #26195 (comment) for info.xml format.
This checks the sabre tags in info.xml for all apps and automatically registers the Sabre plugins and collections to the root collection.
Note that this only happens for v2 remote.php.

Related Issue

Fixes #26195

Motivation and Context

Since we want Webdav to be used for APIs, apps need a way to register Sabre plugins and also to hook their collections to the remote.php/dav collection tree.

How Has This Been Tested?

Manually tested with the customgroups app, not ready yet.

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@DeepDiver1975 check this out

@PVince81 PVince81 added this to the 9.2 milestone Dec 2, 2016
@mention-bot
Copy link

@PVince81, thanks for your PR! By analyzing the history of the files in this pull request, we identified @DeepDiver1975 and @tcitworld to be potential reviewers.

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 2, 2016

  • TODO: also register sabre plugins in v1 endpoint see discussion

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 2, 2016

  • maybe let info.xml specify for which endpoint v1, v2 or both through attributes ?

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 2, 2016

  • TODO: attr to tell whether the plugin needs to be registered also for public webdav ? (mostly for file properties)

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 2, 2016

To demo and test this feature, I tried moving the DAV plugins for the comments into the "comments" app in 64b66d7

So far only the root collection seems to work. Might need further tweaking.

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 2, 2016

  • BUG: looks like IUserSession isn't initialized/populated yet when a plugin's initialize() is called, so makes it difficult to check the current user or check if user is authed (happens in CommentsPlugin):

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 2, 2016

Solved the auth issue by moving the registration of app sabre plugins into beforeMethod handler: 010d4a4

@@ -105,4 +122,84 @@ public function getSyncService() {
return $this->getContainer()->query(SyncService::class);
}

private function registerSabrePluginsFromApps(\OCA\DAV\Server $server) {
\OC_App::loadApps();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

load all apps? in the past we only did load apps of type filesystem to ensure some performance on the dav backend.
new app type? e.g. dav?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A new app type sounds great, I'll add it

}
// FIXME: switch to public API once available
// load commands using info.xml
$info = \OC_App::getAppInfo($app);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

try {
return \OC::$server->query($plugin);
} catch (QueryException $e) {
if (class_exists($command)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$command? unknown

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uh oh... I copied your command code and forgot to replace

try {
return \OC::$server->query($plugin);
} catch (QueryException $e) {
if (class_exists($command)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$command

@DeepDiver1975
Copy link
Member

TODO: also register sabre plugins in v1 endpoint

v1 only holds files - and it's just the old interface - no need to anything new there

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 5, 2016

@DeepDiver1975 ok then we can't port the "comments" app to be a "dav" app with Sabre plugins, because then the comments plugin would be missing in the v1 endpoint.

The other alternative is to change the web UI to use webdav v2: #25494. But then if there's any client who used to expected the oc:comments-unread property on the old endpoint they'd stop working. (but the likeliness of the existence of such clients is very low)

@DeepDiver1975
Copy link
Member

@DeepDiver1975 ok then we can't port the "comments" app to be a "dav" app with Sabre plugins, because then the comments plugin would be missing in the v1 endpoint.

comments arn't even part of v1 as of today - right? So no need to add it

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 5, 2016

comments arn't even part of v1 as of today

Only one piece is: we have a Webdav property on files that is added through the CommentsPlugin. The property is there to tell how many unread comments there are to be able to display an indicator in the UI.
Without this property we'd need to do extra API calls + JS-side joins to be able to add this info to the file list.

@DeepDiver1975
Copy link
Member

Only one piece is: we have a Webdav property on files that is added through the CommentsPlugin. The property is there to tell how many unread comments there are to be able to display an indicator in the UI.
Without this property we'd need to do extra API calls + JS-side joins to be able to add this info to the file list.

I see - lets hardcode this piece and we are fine

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 5, 2016

Hardcode, hmmm... There are multiple levels where we can do this:

  1. Keep CommentsPlugin within the "dav" app
    or
  2. Move the oc:comments-unread property logic to the FilesPlugin. But then it would conflict with the CommentsPlugin one when the "comments" app is enabled.

So I guess 1) is the best approach for now.

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 5, 2016

Rebased onto master to be able to use one of the new IAppManager calls.

Remaining tasks:

  • write unit tests
  • move CommentPropertiesPlugin back to apps/dav for backward compatibility
  • clear out public webdav case (could be done separately as we currently seldom register plugins for that one, but will need it eventually once we do federated metadata, etc)

@PVince81
Copy link
Contributor Author

PVince81 commented Dec 5, 2016

I refactored the whole thing to simplify it.
Wrote a unit test for the plugin manager.

Please review @DeepDiver1975 @jvillafanez @VicDeo @PhilippSchaffrath

First have a look at 07d43a5 which brings the Sabre plugins registration code.
Then see how it's used in ace036b where the comments app is changed to use it.

foreach ($collections as $collection) {
try {
$this->collections[] = $this->container->query($collection);
} catch (QueryException $e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QueryException is unknown

@DeepDiver1975
Copy link
Member

👍

@lock
Copy link

lock bot commented Aug 4, 2019

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.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide API to let apps register their own Sabre plugins
3 participants