Sharing Test for oCIS

[C0rby]

I had a look at why apiVersions/fileVersions.feature:276 was failing with oCIS.

I got the test working with a few changes.
First a fix for version listing: cs3org/reva#1911
And then I had to edit the test a bit.

Scenario: sharer can restore a file inside a group shared folder modified by sharee
    Given user "Brian" has been created with default attributes and without skeleton files
    And user "Carol" has been created with default attributes and without skeleton files
    And group "grp1" has been created
    And user "Brian" has been added to group "grp1"
    And user "Carol" has been added to group "grp1"
    And user "Alice" has created folder "/sharingfolder"
    And user "Alice" has shared folder "/sharingfolder" with group "grp1"
    And user "Alice" has uploaded file with content "First content" to "/sharingfolder/sharefile.txt"
    And user "Brian" accepts share "/sharingfolder" offered by user "Alice" using the sharing API
    And user "Brian" has uploaded file with content "Second content" to "/Shares/sharingfolder/sharefile.txt"
    And user "Carol" accepts share "/sharingfolder" offered by user "Alice" using the sharing API
    And user "Carol" has uploaded file with content "Third content" to "/Shares/sharingfolder/sharefile.txt"
    When user "Alice" restores version index "2" of file "/sharingfolder/sharefile.txt" using the WebDAV API
    Then the HTTP status code should be "204"
    And the content of file "/sharingfolder/sharefile.txt" for user "Alice" should be "First content"
    And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Brian" should be "First content"
    And the content of file "/Shares/sharingfolder/sharefile.txt" for user "Carol" should be "First content"

Before the share recipients upload to the share I added steps for them to accept the share first.
Also I updated the paths for the share recipients to include the /Shares folder.

This means that we probably need to have two versions of the test. The original version for oC10 and this version for oCIS.

[C0rby]

@phil-davis, can you have a look at this and/or delegate this to your team?
I initially wanted to update the test in core myself but then realized that I don't know if my approach would be correct.

[phil-davis]

@phil-davis, can you have a look at this and/or delegate this to your team?
I initially wanted to update the test in core myself but then realized that I don't know if my approach would be correct.

Yes, we will look. I added this to the Test Automation project.

A while ago we separated the sharing tests into:

1. tests that share directly into the root folder, and the share is auto-accepted (that is the default behavior on oC10, and OCIS does not work like that) Those scenario are tagged not to implement on OCIS
2. tests that share to the Shares folder and need to be accepted by the share receiver. Those work on oC10 with the necessary config settings, and is the default behavior on OCIS - so those tests run in CI on both systems

So we need to find all the other tests that use sharing, that are embedded like this in other test suites, and make 2 scenarios for each.

[SwikritiT]

@phil-davis We have test for above scenario that shares to Shares folder here https://github.com/owncloud/core/blob/0de7e405db9dbfd509d799ca9fc08aee85abff19/tests/acceptance/features/apiVersions/fileVersionsSharingToShares.feature#L178

The scenario that shares to the root folder doesn't have @notToImplementOnOCIS but is present in expected to fail file
https://github.com/owncloud/core/blob/0de7e405db9dbfd509d799ca9fc08aee85abff19/tests/acceptance/features/apiVersions/fileVersions.feature#L288

[phil-davis]

@SwikritiT please tag any "sharing to root" scenarios with @notToImplementOnOCIS