reShareUpdate API tests failing in reva master

[phil-davis]

https://drone.cernbox.cern.ch/cs3org/reva/7313/13/6

runsh: Total unexpected failed scenarios throughout the test run:
apiShareReshareToShares3/reShareUpdate.feature:152
apiShareReshareToShares3/reShareUpdate.feature:153

  Scenario Outline: After losing share permissions user can still delete a previously reshared share              # /drone/src/tmp/testrunner/tests/acceptance/features/apiShareReshareToShares3/reShareUpdate.feature:137
    Given using OCS API version "<ocs_api_version>"                                                               # FeatureContext::usingOcsApiVersion()
    And user "Alice" has created folder "/TMP"                                                                    # FeatureContext::userHasCreatedFolder()
    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"       # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/TMP" offered by user "Alice"                                            # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read" # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Carol" has accepted share "/TMP" offered by user "Brian"                                            # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Alice" has updated the last share of "Alice" with                                                   # FeatureContext::userHasUpdatedTheLastShareOfWith()
      | permissions | create,update,read |
    When user "Brian" deletes the last share using the sharing API                                                # FeatureContext::userDeletesLastShareUsingTheSharingApi()
    Then the OCS status code should be "<ocs_status_code>"                                                        # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "200"                                                                      # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And user "Carol" should not have any received shares                                                          # FeatureContext::userShouldNotHaveAnyReceivedShares()

    Examples:
      | ocs_api_version | ocs_status_code |
      | 1               | 100             |
        OCS status code is not any of the expected values 100 got 996
        Failed asserting that an array contains '996'.
      | 2               | 200             |
        OCS status code is not any of the expected values 200 got 996
        Failed asserting that an array contains '996'.

After the API test code changes in core PR https://github.com/owncloud/core/pull/40114 these are failing in reva.

They are passing in oCIS (I will find a CI example of that...)

I will add them to expected failures for now, because it will be good to get the benefit of the core API test code changes running in reva CI.

ToDo:

• [x] find oCIS examples of these test scenarios running
• [ ] understand why they fail now in reva when they used to pass
• [ ] decide what to do next

[kobergj]

Interestingly enough it doesn't fail on the resharing branch: https://github.com/cs3org/reva/pull/2877

It is up to date with edge, so some changes in there seem to fix it.

[kobergj]

Looking closer into it I would strongly suggest that the reason why it passed before is https://github.com/owncloud/core/issues/40093

When user "Brian" deletes the last share using the sharing API

This "last share" was probably some other share and resulted in success. I cannot say which one though. But I can say for sure that it wasn't possible to delete a share without the share permission. I added that functionality in https://github.com/cs3org/reva/pull/2877

[phil-davis]

Note: these scenarios are in oCIS expected-failures:

#### [500 status code on update share](https://github.com/owncloud/ocis/issues/2011)

- [apiShareReshareToShares3/reShareUpdate.feature:152](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareReshareToShares3/reShareUpdate.feature#L152)
- [apiShareReshareToShares3/reShareUpdate.feature:153](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareReshareToShares3/reShareUpdate.feature#L153)

They are linked to a different oCIS issue that no longer seems relevant. An example CI run is: https://drone.owncloud.com/owncloud/ocis/12263/44/7

  Scenario Outline: After losing share permissions user can still delete a previously reshared share              # /srv/app/testrunner/tests/acceptance/features/apiShareReshareToShares3/reShareUpdate.feature:137
    Given using OCS API version "<ocs_api_version>"                                                               # FeatureContext::usingOcsApiVersion()
    And user "Alice" has created folder "/TMP"                                                                    # FeatureContext::userHasCreatedFolder()
    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"       # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/TMP" offered by user "Alice"                                            # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read" # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Carol" has accepted share "/TMP" offered by user "Brian"                                            # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Alice" has updated the last share of "Alice" with                                                   # FeatureContext::userHasUpdatedTheLastShareOfWith()
      | permissions | create,update,read |
    When user "Brian" deletes the last share using the sharing API                                                # FeatureContext::userDeletesLastShareUsingTheSharingApi()
    Then the OCS status code should be "<ocs_status_code>"                                                        # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "200"                                                                      # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And user "Carol" should not have any received shares                                                          # FeatureContext::userShouldNotHaveAnyReceivedShares()
    Examples:
      | ocs_api_version | ocs_status_code |
      | 1               | 100             |
        OCS status code is not any of the expected values 100 got 996
        Failed asserting that an array contains '996'.
      | 2               | 200             |
        OCS status code is not any of the expected values 200 got 996
        Failed asserting that an array contains '996'.

So this does fail in the same way on oCIS.

I will write-up an oCIS issue tomorrow with better details and example curl commands. Then we can link everything to that, and discuss what the behavior should be.

[phil-davis]

The line numbers failing in reva master branch are now:

#### [reShareUpdate API tests failing in reva](https://github.com/cs3org/reva/issues/2916)

- [coreApiShareReshareToShares3/reShareUpdate.feature:158](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares3/reShareUpdate.feature#L158)
- [coreApiShareReshareToShares3/reShareUpdate.feature:157](https://github.com/owncloud/ocis/blob/master/tests/acceptance/features/coreApiShareReshareToShares3/reShareUpdate.feature#L157)

[phil-davis]

The test scenarios pass in the edge branch. For example: https://drone.owncloud.com/cs3org/reva/1406/22/7

  Scenario Outline: After losing share permissions user can still delete a previously reshared share              # /drone/src/tmp/testrunner/tests/acceptance/features/coreApiShareReshareToShares3/reShareUpdate.feature:142
    Given using OCS API version "<ocs_api_version>"                                                               # FeatureContext::usingOcsApiVersion()
    And user "Alice" has created folder "/TMP"                                                                    # FeatureContext::userHasCreatedFolder()
    And user "Alice" has shared folder "/TMP" with user "Brian" with permissions "share,create,update,read"       # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/TMP" offered by user "Alice"                                            # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Brian" has shared folder "Shares/TMP" with user "Carol" with permissions "share,create,update,read" # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Carol" has accepted share "/TMP" offered by user "Brian"                                            # FeatureContext::userHasReactedToShareOfferedBy()
    And user "Alice" has updated the last share of "Alice" with                                                   # FeatureContext::userHasUpdatedTheLastShareOfWith()
      | permissions | create,update,read |
    When user "Brian" deletes the last share using the sharing API                                                # FeatureContext::userDeletesLastShareUsingTheSharingApi()
    Then the OCS status code should be "<ocs_status_code>"                                                        # OCSContext::theOCSStatusCodeShouldBe()
    And the HTTP status code should be "200"                                                                      # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And user "Carol" should not have any received shares                                                          # FeatureContext::userShouldNotHaveAnyReceivedShares()
    Examples:
      | ocs_api_version | ocs_status_code |
      | 1               | 100             |
      | 2               | 200             |

I will leave this issue open, because it is linked from the expected-failures files in reva master. But I will unassign myself.