Skip to content

Conversation

@PVince81
Copy link
Contributor

Description

This makes it possible to retrieve and PROPPATCH the favorite info

Related Issue

None raised, discovered while testing #25494

Motivation and Context

Make new dav behave like old dav

How Has This Been Tested?

Check out this PR #25494 which makes the web UI use the new DAV endpoint.
Favorite a file then refresh the page.
Before: no favorite info.
After: favorited file still appears as favorite.

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.

Please review @DeepDiver1975 @guruz @SergioBertolinSG

This makes it possible to retrieve and PROPPATCH the favorite info
@PVince81 PVince81 added this to the 9.2 milestone Sep 12, 2016
@mention-bot
Copy link

@PVince81, thanks for your PR! By analyzing the annotation information on this pull request, we identified @DeepDiver1975, @LukasReschke and @rullzer to be potential reviewers

@SergioBertolinSG
Copy link
Contributor

SergioBertolinSG commented Sep 13, 2016

The properties are the same as in old webdav endpoint? ("{http://owncloud.org/ns}favorite" with value "1") I'm getting an error so far (404)

@PVince81
Copy link
Contributor Author

@SergioBertolinSG yes, same properties. It's the same plugin with the same behavior.

@PVince81
Copy link
Contributor Author

Very strange... when debugging I can see that the integration test's call is passing the "favorite" property, it also detects it in the plugin's "handleUpdateProperties" but for some strange reason it doesn't go into the handler function.

However if I set the property with cadaver on the new endpoint, it goes there.
Not sure what the difference is, needs more debugging.

@PVince81
Copy link
Contributor Author

From the integration test:

// by property_get
$path                            = (string[6]) 'FOLDER';


// by property_get
$propPatch                       = (object|Sabre\DAV\PropPatch[4]);
  $propPatch->mutations          = (array[1]);
    $propPatch->mutations['{http://owncloud.org/ns}favorite'] = (string[1]) '1';
  $propPatch->result             = (array[0]);
  $propPatch->propertyUpdateCallbacks = (array[0]);
  $propPatch->failed             = (bool) '0';

from cadaver:

// by property_get
$path                            = (string[6]) 'FOLDER';


// by property_get
$propPatch                       = (object|Sabre\DAV\PropPatch[4]);
  $propPatch->mutations          = (array[1]);
    $propPatch->mutations['{http://owncloud.org/ns}favorite'] = (string[1]) '1';
  $propPatch->result             = (array[0]);
  $propPatch->propertyUpdateCallbacks = (array[0]);
  $propPatch->failed             = (bool) '0';

No difference ?!

@PVince81
Copy link
Contributor Author

There's an ignored exception:

  $e->xdebug_message             = (string[5961]) '<tr><th align='left' bgcolor='#f57900' colspan="5"><span style='background-color: #cc0000; color: #fce94f; font-size: x-large;'>( ! )</span> Sabre\DAV\Exception\NotFound: File not found: FOLDER in 'root' in /srv/www/htdocs/owncloud/lib/composer/sabre/dav/lib/DAV/SimpleCollection.php on line <i>91</i></th></tr>

Maybe the test is using the wrong DAV path when setting the property ?

@PVince81
Copy link
Contributor Author

Indeed, dav URL is wrong in the test in changeFavStateOfAnElement:

$url                             = (string[21]) 'remote.php/dav/FOLDER';

This is probably due to the bizarre magic when the path is "remote.php/dav" it gets changed to another one, but doesn't do it for all functions. I suggest to get rid of this and use the expression "when using the old dav path" and "when using the new dav path".

@PVince81
Copy link
Contributor Author

@SergioBertolinSG can you fix the test ?

@SergioBertolinSG
Copy link
Contributor

@PVince81 sure.

@SergioBertolinSG
Copy link
Contributor

@PVince81
Copy link
Contributor Author

Looks like $this->davPath is *always "remote.php/dav" when selecting the new endpoint.
So maybe instead of using it we should use this method instead: https://github.com/owncloud/core/blob/newdav-tagsplugin/build/integration/features/bootstrap/WebDav.php#L27 to get the correct files path.

@SergioBertolinSG
Copy link
Contributor

At that point the url is: remote.php/dav/files/admin/FOLDER

But the propfind is raising an exception HTTP error: 404 (Sabre\DAV\Exception)

@PVince81
Copy link
Contributor Author

Yes, it's using the wrong user...

Because $this->currentUser is "admin" but the user for who to retrieve the properties is "user0".

I think this needs a good refactoring, it's quite messed up.

@SergioBertolinSG
Copy link
Contributor

Ok user is wrong, I'll fix that.

@SergioBertolinSG
Copy link
Contributor

I think this needs a good refactoring, it's quite messed up.

We can improve it in a separate PR, it affects many test cases.

@PVince81
Copy link
Contributor Author

👍 for the tests part

@PVince81 PVince81 merged commit 9c75e10 into master Sep 22, 2016
@PVince81 PVince81 deleted the newdav-tagsplugin branch September 22, 2016 10:38
@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.

4 participants