API tests fail when setting actual resource owner when creating share

[ishank011]

When creating a share, we assume the current user to be the owner of the resource, which won't always be the case, for example, when sharing an already shared resource. The owner should be derived from the ResourceInfo passed (md.Owner).

I tried to change this in #1051, but the API tests didn't pass. So is this expected or should we correct the tests?

@labkode @butonic @individual-it @phil-davis

[phil-davis]

https://cloud.drone.io/cs3org/reva/2133/4/6

  Scenario: orphaned shares                                                               # /drone/src/tmp/testrunner/tests/acceptance/features/apiShareManagementBasic/deleteShare.feature:54
    Given using OCS API version "1"                                                       # FeatureContext::usingOcsApiVersion()
    And these users have been created with default attributes and without skeleton files: # FeatureContext::theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
      | username |
      | Alice    |
      | Brian    |
    And user "Alice" has created folder "/common"                                         # FeatureContext::userHasCreatedFolder()
    And user "Alice" has created folder "/common/sub"                                     # FeatureContext::userHasCreatedFolder()
    And user "Alice" has shared folder "/common/sub" with user "Brian"                    # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
      User Alice failed to share /common/sub with user Brian
      Failed asserting that false is true.
    When user "Alice" deletes folder "/common" using the WebDAV API                       # FeatureContext::userDeletesFile()
    Then the HTTP status code should be "204"                                             # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as "Brian" folder "/sub" should not exist        

That is failing in the Given step that sets up the shares for the scenario. That should not fail. After sending the API request to create the share, it checks the response and expects to find a "user" type share and the share_with field in the response data should have "Brian".

[ishank011]

@phil-davis thanks for the help!

The issue is that owncloud fs returns the prefix of the path as the owner when statting a file, which currently is the username, instead of the opaque ID.
type:RESOURCE_TYPE_FILE id:<storage_id:"123e4567-e89b-12d3-a456-426655440000" opaque_id:"576efd80-2f39-4511-a3c6-1cfd2dee636b" > owner:<opaque_id:"einstein" > ...

This is then passed to the share, which results in something like
"owner":{"opaque_id":"einstein"},"creator":{"idp":"localhost:20080","opaque_id":"4c510ada-c86b-4815-8820-42cdf82c3d51"}

This wouldn't raise any problems when creating the shares, but since we list the shares also on the basis of the owner rather than the creator, share retrieval fails. This should be fixed by #1052, but ideally, we should be able to filter shares both by creator as well as owner, so I've made that change in my PR #1051, and this ensures that all the tests pass.