Shares received in different ways are not merged

[phil-davis]

Describe the bug

See the test scenario.

Steps to reproduce

Steps to reproduce the behavior:

  Scenario Outline: Share receiver renames the received group share and shares same folder through user share again
    Given using OCS API version "<ocs_api_version>"
    And group "grp" has been created
    And user "Brian" has been added to group "grp"
    And user "Alice" has been added to group "grp"
    And user "Alice" has created folder "parent"
    And user "Alice" has created folder "parent/child"
    And user "Alice" has uploaded file with content "Share content" to "parent/child/lorem.txt"
    When user "Alice" shares folder "parent" with group "grp" with permissions "read" using the sharing API
    And user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
    And user "Brian" moves folder "/Shares/parent" to "/Shares/sharedParent" using the WebDAV API
    And user "Alice" shares folder "parent" with user "Brian" using the sharing API
    And user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API
    Then as "Brian" folder "Shares/parent" should not exist
    And as "Brian" folder "Shares/sharedParent" should exist
    And as "Brian" file "Shares/sharedParent/child/lorem.txt" should exist
    Examples:
      | ocs_api_version |
      | 1               |
      | 2               |

Expected behavior

The test should pass - when Brian receives the share of parent again it should be "merged" with the renamed share that Brian has already received through a different way (in this case Brian first received the share because he was a member of a group, and then he received it "directly" as user Brian). A single "merged" view of the share should be presented to Brian.

Actual behavior

Brian sees both Shares/parent and Shares/sharedParent which are actually duplicate renderings of the same folder owned by Alice.

Setup

Current CI in master.

Note: this is similar to core issue owncloud/core#39347

Note: probably the requirement is also that the 2nd share of the same resource does not need to be accepted. So the 2nd And user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API step probably should not be required.

[wkloucek]

related to: owncloud/web#5562

[rhafer]

While testing things with libregraph-idm #3331 , I've run into this testcase. Which shows an interesting behaviour in different configuration. Currently it only seems to succeed with the default oCIS config because the cs3 userprovider does not work correctly with the glauth LDAP service. It's not able to resolve a users group memberships.

If tested with a properly working user/groups backend the test currently fails because the step

And user "Alice" shares folder "parent" with user "Brian" using the sharing API

causes the new share to be automatically accepted, as it is pointing to the same resource as the group share created earlier.

Note: probably the requirement is also that the 2nd share of the same resource does not need to be accepted. So the 2nd And user "Brian" accepts share "/parent" offered by user "Alice" using the sharing API step probably should not be required.

Yeah, removing that step makes the test succeed in case the userprovider is actually able to resolve groups.

@phil-davis @butonic any suggestions how to move forward with this?

[phil-davis]

any suggestions how to move forward with this?

I adjusted the test expectations in core PR owncloud/core#39917

That should make it possible to get oCIS to behave as per the test expectation.

[SagarGi]

@phil-davis with the latest changes the above issue is no more in expected to failure on ocis. the expected to failure related to this issue is removed, is it supposed to be?

[phil-davis]

@phil-davis with the latest changes the above issue is no more in expected to failure on ocis. the expected to failure related to this issue is removed, is it supposed to be?

I see this in oCIS expected-failures-API-on-OCIS-storage.md

#### [Shares received in different ways are not merged](https://github.com/owncloud/ocis/issues/2711)

- [apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:582](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature#L582)
- [apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:583](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature#L583)
- [apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:608](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature#L608)
- [apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature:609](https://github.com/owncloud/core/blob/master/tests/acceptance/features/apiShareCreateSpecialToShares1/createShareReceivedInMultipleWays.feature#L609)

[kiranparajuli589]

@phil-davis after then steps refactorings in owncloud/core#39861
these tests are now passing in the ocis ci https://drone.owncloud.com/owncloud/ocis/10430/25/6

[phil-davis]

Good - then after that is merged we could close this issue.

[kiranparajuli589]

sure @phil-davis, related bump and refactoring PRs are merged. closing this.