Api tests scenario related to share permission needs changes

[amrita-shrestha]

The behavior of share permission is acting differently in ocis and oc10 .
Discussed in this comment: #4052 (comment)
According to this comment, it is actual behavior so we need to refactor our test scenario of share permission in ocis
Related issue

• Share not created with default permissions #1277
• [OCIS] Cannot create public links with permissions. #5248
• Differences of OC10 and OCIS share permissions #4052 ( main discussion happened here)

Example

In this tests scenario permission is 7 but currently permission 7 is unavailable in ocis

  Scenario Outline: Public can or can-not delete file through publicly shared link depending on having delete permissions using the public WebDAV API
    Given user "Alice" has created a public link share with settings
      | path        | /PARENT       |
      | permissions | <permissions> |
    When the public deletes file "parent.txt" from the last public link share using the <public-webdav-api-version> public WebDAV API
    Then the HTTP status code should be "<http-status-code>"
    And as "Alice" file "PARENT/parent.txt" <should-or-not> exist

    Examples:
      | permissions               | http-status-code | should-or-not | public-webdav-api-version |
      | read,update,create        | 403              | should        | new                       |

QA Todo

• search for similar tests scenario which uses share permission refactor scenario (there are other permission which behave different in oc10 and ocis please check in detail)
• remove the issue from the expected-failure file

[amrita-shrestha]

1. Permission 7 (read, update,create)

• OCIS - Share not created

<?xml version="1.0" encoding="UTF-8"?>
<ocs>
  <meta>
    <status>error</status>
    <statuscode>400</statuscode>
    <message>Could not read permission from request</message>
  </meta>
</ocs>

• OC10 - Share with permission 1 is created. Viewer role assigned.

@kobergj @kulmann @fschade @individual-it @phil-davis @SwikritiT is this actual behavior?

[kulmann]

@micbar ^

[phil-davis]

IMO the currently-implemented general rule is:

In oC10: ignore permissions that are not useful/relevant to the resource (for example, create permission is not relevant to a shared file - the file is already created when it is shared). Mask off the irrelevant permission bits, and create (or update) the share with just the useful permission bits from those requested.

In ocis: if the requested permissions include permissions that are not useful/relevant to the resource, then fail the request. The client must request only permission bits that are useful/relevant.

Can someone confirm that these 2 different implementations are both acceptable?

Then we can make the understand what to expect for each backend.

[micbar]

Can someone confirm that these 2 different implementations are both acceptable?

@phil-davis Thanks for your analysis. That is obviously a difference. From my POV, the permission bitmask is nearing deprecation an is only be there because of legacy reasons. I am always against "magical" Api behavior, especially in this case where we are dealing with permissions. The API should return "Bad Request" and a reason.

Conclusion: we accept the behavior as it is.

[phil-davis]

@amrita-shrestha you (or you can assign someone) can "skip on ocis" the oC10 scenarios that fail because of this different behavior. Then out scenarios that demonstrate the agreed ocis behavior.

Maybe it will be easiest to have examples for ocis in the existing scenario outlines?

Anyway, however you do it, coordinate with @kiranparajuli589 as he copies various parts of the core acceptance tests across to the ocis repo - we don't want to accidentally lose anything.

[saw-jan]

Will be blocked until #5094 is completed
Copying task has been completed with PRs #5280 and #5306

[amrita-shrestha]

• coreApiSharePublicLink1 [full-ci][tests-only]Forward-port refactor share permission in coreApiSharePublicLinkShare #5490 [full-ci][tests-only]Refactor share permission in coreApiSharePublicLinkShare #5494
• coreApiSharePublicLink2 [tests-only][full-ci]Refactor share permission related scenario in coreApiSharePublicLink2 #5501 [tests-only][full-ci]Forward-port Refactor share permission related scenario #5508
• coreApiSharePublicLink3 [tests-only][full-ci]Refactor share permission related scenario in coreApiSharePublicLink3 #5502 [tests-only][full-ci]Forward-port refactor share permission related scenario #5561

[amrita-shrestha]

all PR has been merged so closing this issue